UNIVERSIDAD NACIONAL AUTÓNOMA DE

MÉXICO

FACULTAD DE CONTADURÍA Y ADMINISTRACIÓN

Licenciatura En Informática

Bases de
Datos
Autor: L.I. María de Lourdes Isabel
Ponce Vásquez

AGOSTO - DICIEMBRE 2008

 Contenido
UNIDAD 4. MODELO ORIENTADO A OBJETOS................................................................................................3
Objetivos Específicos.......................................................................................................................3
4.1. Introducción..............................................................................................................................3
4.1.1. Retos Actuales de los DBMSs............................................................................................3
4.1.2. Tendencias Actuales en la Tecnología de BD....................................................................4
4.1.1.1. Rendimiento.................................................................................................................5
4.1.1.2. Distribución/Integración................................................................................................5
4.1.1.3. Funcionalidad/Inteligencia............................................................................................5
4.1.3. Orientación a Objetos.........................................................................................................5
4.1.1.4. Principios Fundamentales de la POO...........................................................................6
4.1.1.5. Modularidad.................................................................................................................6
4.1.1.6. Abstracción..................................................................................................................7
4.1.1.7. Objetos.........................................................................................................................7
4.1.1.8. Clases..........................................................................................................................8
4.1.1.9. Encapsulamiento..........................................................................................................8
4.1.1.10. Interrelaciones............................................................................................................8
4.1.1.11. Polimorfismo...............................................................................................................9
4.1.4. Persistencia........................................................................................................................9
4.2. Sistemas de Administración de BDOO....................................................................................10
4.2.1. Antecedentes...................................................................................................................10
4.2.2. Primera Generación.........................................................................................................10
4.2.3. Segunda Generación.......................................................................................................11
4.2.4. Tercera Generación.........................................................................................................12
4.2.5. Definición.........................................................................................................................12
4.2.6. Características.................................................................................................................13
4.1.1.12. Persistencia..............................................................................................................13
4.1.1.13. Modelo de objetos....................................................................................................14
4.1.1.14. Lenguaje de Datos...................................................................................................14
4.1.1.15. Arquitectura de tres niveles......................................................................................14
4.1.1.16. Optimizador..............................................................................................................14
4.1.1.17. Seguridad.................................................................................................................14
4.1.1.18. Interfaces para Programas de Aplicación (API)........................................................14
Diccionarios de datos..............................................................................................................15
4.1.1.19. Herramientas para desarrollo de aplicaciones..........................................................15
4.1.1.20. Herramientas para la transformación de datos.........................................................15
4.1.1.21. Utilidades para mantenimiento y mejora del rendimiento de la BD...........................15
4.1.1.22. Soporte de datos multimedia....................................................................................15
4.1.1.23. Herramientas y Facilidades de Usuario....................................................................15
4.1.1.24. Distribución...............................................................................................................15
4.1.1.25. Control de versiones y configuraciones....................................................................16
4.3. Estándar ODMG.....................................................................................................................16
4.3.1. Ejemplos..........................................................................................................................17

Unidad 4. Modelo Orientado a Objetos Página 2

 UNIDAD 4. MODELO ORIENTADO A OBJETOS

Objetivos Específicos
 Describir los retos y tendencias actuales de los DBMS
 Comprender el paradigma orientado a objetos
 Conocer los orígenes de las bases de datos orientadas a objetos
 Definir y describir las características del modelo orientado a objetos
 Describir y comprender el estándar ODMG
4.1. Introducción
En la unidad anterior se revisó el modelo relacional para almacenar los datos en una base de datos,
en esta unidad se revisará el modelo orientado a objetos y el modelo objeto relacional que ha ganado
terreno en el entorno de bases de datos.

Como se mencionó, los OODBMS (Administradores de Bases de Datos Orientadas a Objetos)

surgieron por la falta de capacidad semántica del modelo relacional para soportar aplicaciones
complejas, como CAD/CAM, CASE, sistemas basados en conocimiento, tratamiento de documentos,
multimedia y gestión de redes, etc., que necesitan modelación directa de objetos e interrelaciones
complejas, el almacenamiento de información no estructurada, gestión de diversos tipos de
transacciones, control exhaustivo de componentes y estructuras, además de manejar diversas
versiones y configuraciones.

Los OODBMS eliminan las barreras entre los datos y procesos encapsulando datos y las
operaciones sobre ellos. Esta tendencia ya aparecía en versiones de productos relacionales que
permiten desde los 90s, almacenar disparadores (triggers), reglas (restricciones) y procedimientos
almacenados.

Otra ventaja de los OODBMS es la reducción de la distancia en el desarrollo entre el modelo

conceptual (E/R ó UML) y el modelo lógico, ya que el paradigma de la orientación a objetos (PaOO)
proporciona un único modelo implementado en el OODBMS, al que acceden directamente las
aplicaciones.

4.1.1. Retos Actuales de los DBMSs

La última generación de BD ha demostrado que aún no se pueden resolver todos los problemas de
almacenamiento que teóricamente debían resolverse con el uso de las BD, algunos de estos
problemas son:

 Los DBMS actuales son monolíticos; ofrecen todo tipo de servicios y funcionalidades en un
solo paquete, sin considerar las necesidades específicas de los usuarios, esto provoca un
alto costo y pérdida de eficiencia.
 A la fecha siguen existiendo más datos en hojas de cálculo que en DBMSs por la facilidad y
simpleza que estos sistemas ofrecen en comparación con los DBMSs.
 Se cree que cerca del 50% de los datos de producción se encuentran todavía en sistemas
heredados (sin DBMSs) sin poder llevar toda la información a un DBMS.

Unidad 4. Modelo Orientado a Objetos Página 3

  Los sistemas de gestión de flujos de trabajo (workflow) y muchos otros no están basados en
tecnología de BD, simplemente acceden a la BD a través de Interfaces de Programas de
Aplicación (APIs).
 Los servicios de replicación están limitados por lo que no se extienden a más de 10,000
nodos.
 Es difícil combinar datos estructurados y no estructurados en una BD (por ejemplo
provenientes de correos electrónicos).

Las BD son el núcleo de los SI y por tanto se ven influenciadas por los cambios que sufren las
empresas, por lo que deben ofrecer a las organizaciones flexibilidad, tiempos bajos de respuesta,
robustez, extensibilidad, gestión de la incertidumbre, etc. La integración de datos estructurados y no
estructurados es muy importante y los DBMS deben ofrecer este servicio. La globalización y
competitividad internacional influyen en la tecnología, la cual debe proporcionar conectividad entre
las BD distribuidas geográficamente, siendo capaces de integrar rápidamente BD separadas
(protocolos, distribución de datos, federaciones, etc.) y ofrecer disponibilidad 100% (las 24 horas del
día durante los 365 días del año). Los nuevos productos de BD deben ayudar al usuario a la
localización de los datos distribuidos y a la conexión de las aplicaciones en las PC con las BD locales
y remotas.

4.1.2. Tendencias Actuales en la Tecnología de BD

Los avances en hardware tienen gran impacto en el desarrollo actual de las BD. La reducción de
precio de RAM y disco han proporcionado equipos con más potencia a precios más bajos. Este factor
ha afectado algunos algoritmos de los DBMS, permitiendo que grandes volúmenes de datos sean
almacenados RAM. También, la arquitectura paralela (Multiprocesadores Simétricos – SMP -
Symmetryc Multi-Processing y Procesadores Masivamente Paralelos – MPP Massively Parallel
Processing) ofrece la posibilidad de ejecutar los DBMS en varios procesadores.

Otras tecnologías que también están influyendo a los cambios son: técnicas de
compresión/descompresión, digitalizadores de audio y video, medios de almacenamiento óptico,
discos magnéticos, medios de almacenamiento jerárquico, etc.

Las computadoras asistentes personales, PDA (Personal Digital Assistant), palmtops, laptops, etc.,
permiten acceder a la información en cualquier sitio y momento. Eso plantea problemas de
conectividad y afecta la distribución de las BD.

El modelo C/S con la introducción de la arquitectura de dos capas se ha transformado con los
monitores Middleware y TP (Procesamiento de Transacciones – Transaction Processing).

Las redes de alta velocidad (Ethernet rápida, AnyLan, FDDI – Interfaz de Datos Distribuidos en Fibra,
DQDB – Bus Dual de Colas Distribuidas-, Frame Relay, etc.) han cambiado también la capa de
comunicación donde se sitúan las BD.

Recientemente, la aparición de la tecnología GRID, que pretende conectar computadoras con el fin
de proporcionar una potencia de cálculo mayor y usar los ciclos de procesador desperdiciados,
también plantea interesantes desafíos de metadatos, seguridad, interoperabilidad, rendimiento, etc. a
las BD.

Las DB han evolucionado en tres aspectos: rendimiento, distribución/integración y funcionalidad.

Unidad 4. Modelo Orientado a Objetos Página 4

4.1.1.1. Rendimiento

Las BDs han evolucionado implementando BD paralelas con memoria compartidas, disco compartido
o nada compartido, explotando tanto el paralelismo en las inter-consultas, que realizan diversas
consultas en varios procesadores independientemente; como en la intra-consulta, que realizan
fragmentos de una misma consulta en diferentes procesadores. Y en estos últimos años han
aparecido BD que explotan las ventajas del gris.

En aplicaciones de respuesta crítica el rendimiento se mejora fijando prioridad para las transacciones
en tiempo real.

También para mejorar el rendimiento, las BD en memoria principal cambian algunos conceptos de
estructuras de índices, agrupaciones, bloqueos, transacciones, etc.

4.1.1.2. Distribución/Integración

La distribución de BD se ha ampliado a BD Móviles que son sistemas distribuidos en los que los
enlaces entre los nodos cambian dinámicamente.

Se ha ampliado la integración en Internet. La Web agrega nuevos componentes incluyendo las IGUs,
un nuevo modelo C/S (protocolo http) y un mecanismo de hiperenlace entre BD.

4.1.1.3. Funcionalidad/Inteligencia

En este punto, cada vez más, la semántica y funcionalidad se ha migrado a los DD, almacenándose
junto con los datos, de modo que se libere a las aplicaciones de comprobar restricciones de
integridad y duplicándose en todos los programas, y convirtiéndose en BD semánticas. A principios
de los 90 aparecieron las bases de datos activas, donde la descripción de los datos y las
restricciones, se almacenan en la BD y pueden ejecutar aplicaciones sin la intervención del usuario
soportando disparadores, reglas, alertas, demonios, etc.

Las OODB y ORDD permiten la definición y gestión de los objetos, donde los objetos pueden ser de
cualquier tipo: imágenes, audio, video, etc. (BD multimedia) o datos geográficos (BD espaciales).

Recientemente han aparecido las BD semiestructuradas, adecuadas para gestión de documentos

XML, que aportan un nuevo modelo de datos.

4.1.3. Orientación a Objetos

La Orientación a Objetos se puede definir como "una disciplina de ingeniería de desarrollo y
modelado de software que permite construir más fácilmente sistemas complejos a partir de
componentes individuales".

La Orientación a Objetos permite una representación más directa del mundo real, reduciendo
fuertemente la transformación radical normal desde los requerimientos del sistema, definidos en
términos del usuario, a las especificaciones del sistema, definidas en términos de la computadora. En
vez de tratar de modelar un problema en algo familiar a la computadora se trata de acercar la
computadora al problema, es decir, modelar el problema mediante entidades independientes que

Unidad 4. Modelo Orientado a Objetos Página 5

interactúan y cuyas fronteras no están determinadas por su instrumentación computacional sino por
la naturaleza del problema.

4.1.1.4. Principios Fundamentales de la POO

Algunos autores centran los principios fundamentales que configuran el paradigma orientado a
objetos, en tres características:
 Abstracción
 Herencia
 Identidad de los Objetos

Otros más estiman que la OO se basa sólo en:

 Herencia
 Encapsulamiento o encapsulación
 Polimorfismo

Mientras que otros señalan siete u ocho de los siguientes aspectos como básicos a considerar para
una verdadera orientación al objeto:

 Modularidad
 Abstracción
 Objetos
 Clases
 Encapsulamiento
 Herencia
 Polimorfismo y enlace dinámico
 Persistencia

4.1.1.5. Modularidad

La modularidad consiste en dividir un programa en partes llamadas módulos, los cuales pueden
trabajarse por separado. En términos de programación, los módulos pueden compilarse por
separado y la división no depende de cierto número de líneas sino es una división en términos de
integrar en un módulo un conjunto de procedimientos relacionados entre sí, junto con los datos que
son manipulados por tales procedimientos.

El objetivo de la modularidad es reducir el costo de elaboración de programas al poder dividir el

trabajo entre varios programadores y aumentar la productividad.

Por ejemplo, un automóvil está constituido por un conjunto de módulos tales como un sistema
eléctrico, uno mecánico y uno de frenado. Cada módulo se trabaja por separado y el especialista
sólo conoce la forma en que se relaciona el módulo con los otros, pero no tiene por qué saber los
detalles de funcionamiento de otros módulos o sistema.

Estos conceptos no son exclusivos de la OO, pues se han desarrollado desde la programación
estructurada, sólo que en ésta se pueden omitir (desde luego bajo responsabilidad del programador),
pues hacerlo, lleva a tener grandes programas en un solo archivo y sin estructura alguna, lo cual
causa grandes pérdidas de tiempo al desear modificar tal programa.

Unidad 4. Modelo Orientado a Objetos Página 6

La OO no puede lograrse sin hacer uso de los mecanismos antes mencionados y para ello,
proporciona los medios para ir creando módulos llamados clases. En las clases, cada tipo no simple
es un módulo, y cada módulo de alto nivel es un tipo.

4.1.1.6. Abstracción

La abstracción es una descripción o especificación simplificada de un sistema que hace énfasis en

algunos detalles significativos y suprime los irrelevantes.

La abstracción es esencial para construir cualquier sistema, sea o no orientado a objetos y debe
enfocarse más en qué es un objeto y qué hace, antes de pensar en la implementación.

Por ejemplo, un automóvil puede abstraerse como un objeto que sirve para desplazarse a mayor
velocidad, sin importar cómo lo haga.

Una característica de la abstracción es que un objeto puede abstraerse de diversas formas,

dependiendo del observador. Así, el automóvil que se mencionaba puede ser visto como un objeto
de colección por un coleccionista, una herramienta de trabajo por un corredor profesional, una
mercancía por un vendedor, etc.

4.1.1.7. Objetos

A pesar de que el punto central en esta nueva metodología de programación es el concepto de

objeto. En términos de programación, un objeto es: “un concepto, abstracción o cosa con límites
bien definidos y significado para una aplicación”. Lo que sí puede decirse de todo objeto es que tiene
estado, comportamiento e identidad.

El estado de un objeto abarca todas las propiedades o características distintivas del mismo y los
valores de cada una de estas propiedades. En términos de programación, puede decirse que las
propiedades son las variables que sirven para describir tal objeto.

El comportamiento es la forma como actúa o reacciona un objeto en términos de cambio de estado,

envío y recepción de mensajes. Está formado por la definición de las operaciones (funciones y
procedimientos) que puede realizar este objeto. Los tipos más comunes de operaciones, o en POO
métodos, son: modificar, seleccionar, iterar, construir y destruir. El conjunto de operaciones que un
objeto puede realizar sobre otro, se conoce como protocolo.

Identidad (OID – object identifier) es la propiedad de un objeto que lo distingue de todos los demás.
Un objeto conserva su identidad aún cuando algunos o todos los valores de los atributos o las
definiciones de los métodos cambien con el tiempo, este concepto de identidad no se aplica a las
tuplas de una BD relacional, en estos sistemas, las tuplas se distinguen por los valores que
contienen.

La identidad de un objeto es una noción más fuere que la que se encuentra normalmente en los
lenguajes de programación o en los modelos de datos no OO. Algunas formas de identidad son:

Valor. Se usa un valor de dato por identidad. Esta es la forma usada en los sistemas
relacionales.
Nombre. Se usa un nombre dado por el usuario. Esta es la forma usada en los lenguajes de
programación para identificar a cada variable dentro de un programa.

Unidad 4. Modelo Orientado a Objetos Página 7

 Incorporación. Se incorpora en el modelo de datos el lenguaje de programación y no se
requiere que el usuario proporcione algún identificador. Esta es la forma que se usa en las
BD orientadas a objetos.

Por ejemplo, un automóvil puede tener diversos estados, puede estar estacionado o en circulación.
Un comportamiento asociado con el auto pueden incluir encenderlo, lo cual modifica su estado, y
generalmente tiene una identidad marca, modelo, número de serie del motor y placa.

4.1.1.8. Clases

Una clase es un módulo y un tipo de datos abstracto que define un grupo de objetos que comparten
características comunes.

Por ejemplo, se puede hablar de autos como una clase y mencionar propiedades compartidas tales
como los asientos o parabrisas, pero también se pueden emplear los valores de los atributos para
distinguir a un miembro de la clase de otro (un auto de carreras corre a una mayor velocidad). Así,
una clase describe un conjunto de objetos que comparten una estructura común y tienen
comportamientos comunes, pero los valores de los atributos permiten distinguir a unos de los otros.

4.1.1.9. Encapsulamiento

El encapsulamiento es una técnica para empaquetar la información, envolviendo los atributos y

métodos de los objetos en clases, de tal forma que se oculte lo que debe ocultarse y haga visible lo
que está pensado para serlo.

Con esto se trata de lograr que al tener algún cambio en la implementación de un objeto no se
tengan que modificar los programas que utilizan tal objeto.

Siguiendo con el ejemplo del automóvil, se sabe que existen diversos mecanismos para que funcione
éste, en particular se tiene el sistema de frenado que todo mundo sabe que sirve para detener el
auto al pisar el pedal de freno, pero sólo el mecánico sabe los detalles de la implementación. Por otro
lado, si en algún momento se cambia, para el conductor es transparente.

4.1.1.10. Interrelaciones

La herencia que es la una relación entre clases donde las características y el comportamiento
general de una superclase puede compartirse con sus subclases, permite que una clase sea definida
como una extensión o restricción de otra y es la contribución más importante de la POO, pues
mediante este mecanismo es posible lograr la principal meta de la OO que es la reutilización de
código.

La herencia permite definir una jerarquía de clases. En tal jerarquía, algunas clases son
subordinadas a otras llamadas subclases.

Una subclase define el comportamiento de un conjunto de objetos que heredan algunas de las
características de la clase padre, pero adquieren características especiales no compartidas por el
padre, en este sentido se dice que la subclase es una especialización de la clase padre.

Unidad 4. Modelo Orientado a Objetos Página 8

La herencia múltiple y repetida permite que se pueda declarar una clase como heredera de varias,
e incluso de ella misma.

La herencia simple permite heredar sólo de una clase padre. En estos casos, se implementan las
llamadas interfaces que permiten simular la herencia múltiple.

Otro tipo de interrelación muy importante en este modelo es la agregación, que permite construir
objetos complejos o compuestos a partir de otros, correspondiendo a la noción “parte-de” ó “tiene
un”. Por ejemplo un auto tiene un motor.

La genericidad es otra forma de interrelación que es la capacidad de definir clases parametrizadas

(genéricos), creando una plantilla que permite construir tipos. Por ejemplo, se puede definir un vector
de elementos de tipo “X”, siendo “X” el parámetro formal que se sustituye por el parámetro real
cuando se requiere construir el tipo concreto, por ejemplo un vector de números enteros, de
personas, de vectores, etc.

4.1.1.11. Polimorfismo

El polimorfismo es la capacidad de tener métodos con el mismo nombre pero con una
implementación diferente o que un método sea aplicable a diferentes tipos de argumento.

Por ejemplo, al tratar de frenar un auto siempre se debe oprimir el pedal del freno y el vehículo se
detendrá sin importar si los frenos son de tambor o de disco.

Una implementación específica de un comportamiento para una cierta clase se denomina método.
En un sistema polimórfico, un comportamiento puede tener más de un método que lo implemente.
Por ejemplo, existirá un método frenar cuando se trata de frenos de disco y otro cuando son de
tambor pero el método sigue siendo frenar.

Las dos principales formas de polimorfismo son:

Sobrecarga. Se utiliza el mismo nombre para diferentes servicios, que se distinguen por la
cantidad y tipos de parámetros, éstos no requieren herencia.
Sobrescritura. Cuando una subclase redefine un servicio manteniendo el mismo nombre.

Un lenguaje de programación OO se diseña para seleccionar automáticamente el método correcto

para implementar la operación, a partir de los datos asociados con la operación como parámetros, y
el nombre de la clase de objeto, esto es llamado enlace dinámico (dinamic binding). El enlace
dinámico, permite que las entidades del programa puedan referenciar en tiempo de ejecución a
objetos de diferentes clases y está íntimamente relacionado con el concepto de herencia. En el
ejemplo del frenado, el objeto seleccionará el método de frenado apropiado, basado en los
parámetros que describen el tipo de frenos.

4.1.4. Persistencia
La última propiedad asociada con sistemas OO es la persistencia, que es la capacidad del nombre,
estado y comportamiento de un objeto para trascender el espacio o el tiempo. En otras palabras, el
nombre, estado y comportamiento de un objeto se pueden conservar aún cuando el objeto es
transformado o destruido.

Unidad 4. Modelo Orientado a Objetos Página 9

Una vez almacenado en memoria secundaria, se puede reconstruir para usarlo durante la ejecución
(materialización del objeto).

Por ejemplo, se puede desear guardar información del mantenimiento de un auto, para poder
comparar los ajustes y modificaciones que se le han realizado. En este caso, el objeto persiste aun
cuando sus atributos se transformen.

4.2. Sistemas de Administración de BDOO

4.2.1. Antecedentes
La historia de las BD se extiende desde mediados de los 60s y se ha caracterizado por su
excepcional productividad e impresionante impacto económico. A continuación se muestra un
resumen de las últimas décadas de evolución.

4.2.2. Primera Generación

Desde que empezaron a usarse las computadoras para automatizar la administración de las
empresas, la evolución de los sistemas de información ha tenido impacto en la gestión de los datos,
al exigir cada vez más prestaciones de la información almacenada en los sistemas. Gradualmente, el
enfoque de la informática, inicialmente concentrado en el proceso donde los datos se almacenaban
en archivos específicos para cada aplicación, se fue desplazando hacia sistemas orientados a los
datos, en los que los datos se almacenan en BD y representan un papel fundamental para los
ingenieros de sw. Actualmente, muchos de los problemas del diseño de los sistemas de información
se centran en el modelo y estructuración de los datos.

Tras los complejos sistemas de archivos de las primeras etapas de la informática, en las décadas 60
y 70 nació la primera generación de productos de BD. Los primeros DBMS que se basaron en los
modelos jerárquicos y en red, proporcionaban una organización lógica de los datos en árboles y
grafos. Si bien eran sistemas bastante eficientes, este tipo de productos usaba lenguajes
procedimentales, no poseían la suficiente independencia físico/lógica y su flexibilidad era muy
limitada. Sin embargo, lograron varios avances comparados con los sistemas de archivos.

La incorporación a los DBMS de facilidades de comunicación de los datos con IMS de IBM, dio lugar
al primer sistema BD/DC (Data Base/Data Communication) a gran escala, en el que muchos usuarios
accedían a la BD a través de una red de comunicación. Desde entonces, los DBMS comerciales
ofrecen acceso a BDs en red, siendo esta la forma habitual de uso de BD.

Bachean fue pionero en el desarrollo de los sistemas de BD en red. En su artículo “El Programador
como Navegador”, describe el proceso de navegar a través de una BD, en el que el programador
tiene que seguir un camino explícito, registro a registro, en la búsqueda de un conjunto de datos. En
sus especificaciones de 1978, Codasyl propuso un Lenguaje de Definición de Datos (DDL) en tres
niveles (Schema DDL, Subesquema DDL e Internal DDL) y una normativa para poder manipular los
datos en el DML de tipo procedimental.

Los enlaces jerárquicos y los conjuntos Codasyl se implementaron físicamente mediante

apuntadores. Esta implementación, junto a las restricciones funcionales de estos enlaces y
conjuntos, son las causas de los puntos débiles de los sistemas basados en estos modelos (poca

Unidad 4. Modelo Orientado a Objetos Página 10

flexibilidad en las estructuras físicas, dependencia datos/aplicaciones, y complejidad de los lenguajes
de navegación). Sin embargo, estos mismos apuntadores son precisamente la razón de su eficiencia,
uno de los puntos fuertes de este tipo de productos. Esta generación está orientada principalmente al
procesamiento por lotes.

4.2.3. Segunda Generación

Los productos relacionales se consideran la segunda generación de BD; productos como Oracle,
DB2, etc., proporcionan mayor independencia física/lógica, mayor flexibilidad y lenguajes de consulta
declarativos, en los que los usuarios indican qué quieren obtener sin describir cómo hacerlo. Con los
RDBMSs, las organizaciones también tienen más facilidad para distribuir sus datos. Además los
RDBMSs proporcionan una base teórica más sólida. A diferencia de los modelos anteriores, el
modelo relacional está orientado a valores y no soportan la identidad de los objetos.

A finales de los 70 y durante los 80s, los trabajos se centraron en la optimización de las consultas,
lenguajes de alto nivel, teoría de la normalización, organizaciones físicas para el almacenamiento de
las relaciones, algoritmos para la gestión de memorias intermedias (buffers), técnicas de indexación
(variaciones de los árboles B), sistemas distribuidos, dd, gestión de transacciones, etc. Estas
investigaciones tuvieron como consecuencia un aumento de la eficiencia y la seguridad de los
entornos transaccionales en línea (OLTP); tema fundamental en la 2ª generación de BD.

En los 80s se estandarizó SQL, con la mayoría de los productos ofreciendo una interfaz SQL, aún los
no relacionales.

Muchos avances en la tecnología de BD se basaron en dos elementos base: la arquitectura y los

modelos de datos. Respecto a la arquitectura, las propuestas de ISO y ANSI sobre los modelos de
referencia, influyeron positivamente no sólo en las investigaciones teóricas, sino también en las
aplicaciones prácticas. En la mayoría de los modelos de referencia se pueden encontrar dos
conceptos principales: la arquitectura de tres niveles (externo, lógico e interno), también propuesta
por Codasyl en el 78, y la descripción recursiva de los datos. La separación entre la apariencia lógica
de los datos y su implementación física ha sido siempre un objetivo importante en la evolución de las
BD, y la arquitectura de tres niveles, junto con el modelo relacional, ha sido uno de los principales
avances en este sentido.

En cuanto a los modelos de datos, el modelo relacional fue el que marco las líneas de investigación
en las décadas de los 70 y 80, siendo soportado por la mayoría de los productos actuales. En los 90
surgieron otros DBMS basados principalmente en modelos de objetos. En los últimos años, con el
auge del lenguaje XML, los DBMS están soportando la gestión de este tipo de información con
modelos XML puros o implantándolos como una capa sobre el modelo relacional.

Pueden citarse tres factores clave en la evolución de las BD: los fundamentos teóricos, los productos
y las aplicaciones prácticas. Estos factores han estado siempre presentes a lo largo de la historia de
las BDs, pero el equilibrio entre ellos ha cambiado. Las BDs empezaron en los 60 como un producto
tecnológico demandado por las necesidades de los usuarios, y pasaron a convertirse durante los 70
y 80s en una gran industria y un mercado importante. Aunque las necesidades de los usuarios han
influido en esta evolución, fue hasta los 90 que la tecnología ha sido guiada por las demandas de los
usuarios.

En los últimos años la tecnología de BD ha obtenido grandes avances, temas que parecían al
principio exclusivos de laboratorios y centros de investigación, han aparecido en las últimas
versiones comerciales: multimedia, orientación a objetos, seguridad, temporalidad (incorporan el
tiempo), paralelismo, BD multidimensionales, semiestructuradas, gril, etc.

Unidad 4. Modelo Orientado a Objetos Página 11

4.2.4. Tercera Generación
Muchas aplicaciones no tradicionales no usaban tecnología de BD por que sus necesidades
especiales. Los DBMS han puesto atención a estas aplicaciones para proporcionar respuestas a
estas necesidades, por lo que casi todos los proveedores comenzaron a incorporar nuevas
funcionalidades a sus productos para proporcionar soluciones a estos problemas. Al mismo tiempo,
los avances en hw y sw y los cambios en la organización de las empresas también obligaron el
nacimiento de una nueva generación de BD.

Esta generación se caracteriza por “proporcionar capacidades de gestión de datos igual que las
anteriores, permitiendo que grandes cantidades de datos persistentes sean compartidos por muchos
usuarios. También proporcionan gestión de objetos, permitiendo tipos de datos mucho más
complejos, objetos multimedia, datos derivados, encapsulamiento de la semántica de los datos, así
como otras nuevas capacidades. Algunos proporcionan incluso gestión de conocimiento,
soportando un gran número de reglas complejas para inferencia automática de información y
también para mantener las restricciones de integridad entre datos”.

4.2.5. Definición
Existen dos enfoques principales de implementación de BD de objetos. El primero, extiende los
RDBMS para que soporten los conceptos de orientación a objetos creando las BD Objeto-
Relacionales. Por otro lado, están las BD Orientadas a Objetos que soportan un modelo de objetos
puro y no son extensiones de otros modelos, como O2, Objectivity, ObjectStore, Ontos, Itasca,
Versant, Jasmine, Fast Objects, etc.

Las BD Objeto-Relacionales tienen una serie de reglas descritas en el “Manifiesto de los Sistemas
de BD de Tercera Generación” de Stonebraker (1990), y son cumplidas por la mayoría de los
proveedores relacionales actuales:

1er. Principio: “Además de los servicios tradicionales de gestión de datos, los DBMS de
tercera generación proporcionarán gestión de objetos y reglas más amplio”:
o Un DBMS debe tener un sistema de tipos amplio.
o Debe manejar herencia.
o Debe permitir definir métodos y encapsulamiento.
o Debería asignar OID para las tuplas sólo si no está disponible una llave primaria.
2º. Principio: “Los DBMS de tercera generación deben incluir a los DBMS de segunda
generación”:
o Deben tener un lenguaje de acceso declarativo y de alto nivel.
o Deben existir dos formas de especificar las colecciones: por enumeración de
miembros o mediante un lenguaje de consultas.
o Las vistas deben ser actualizables.
o Los indicadores de resultado no deben aparecer en los datos.
3er. Principio: “Los DBMS de tercera generación deben ser abiertos a otros subsistemas”:
o Debe ser accesible desde múltiples lenguajes de alto nivel.
o Deben soportar persistencia de variables.
o SQL debe ampliarse para la expresión de datos.
o Las consultas y sus respuestas deben ser el nivel más bajo de comunicación C/S.

Unidad 4. Modelo Orientado a Objetos Página 12

Por su parte, las BD Orientadas a Objetos son más completas y describen sus características en el
“Manifiesto de Sistemas de BD Orientadas a Objetos” de Atkinson (1989), estas reglas se cumplen
por los OODBMS y se refieren al soporte de:

Objetos complejos
Identidad del objeto
Encapsulamiento
Tipos y clases
Jerarquías de tipos o clases
Polimorfismo, sobrecarga y enlace dinámico
Compleción de cálculos
Extensibilidad
Persistencia
Gestión del almacenamiento secundario
Concurrencia
Recuperación
Facilidad de consulta

Junto con cinco características opcionales que serían convenientes presentar:

Herencia múltiple
Verificación de inferencia del tipo
Distribución
Transacciones de diseño
Versiones

Este manifiesto fue el primero que se elaboró, se presentó como una propuesta ante la falta de
acuerdos en las características de los OODBMS y, por ello, los autores aconsejan “cuestionar las
reglas”.

4.2.6. Características
Las características de estos sistemas provienen de la unión de BD y OO. Las características que
indica el ANSI (1990b) son consideradas como modelo de referencia abstracto, y que, no indica una
especificación implementable, sino una exposición general y un punto de comparación.

4.1.1.12. Persistencia

En los OODBMS los objetos son permanentes almacenados en la BD hasta borrarlos de modo
explícito, a diferencia de los objetos en los LP. Existiendo distintas posibilidades:

Todos los objetos son persistentes.

La persistencia es una propiedad del tipo de objeto, generalmente definida como subtipos
de un tipo persistente.
El objeto se designa persistente al crearse.
Existe alguna operación que hace a un objeto persistente.

Unidad 4. Modelo Orientado a Objetos Página 13

4.1.1.13. Modelo de objetos

A diferencia del modelo relacional, el modelo de objetos es más realista, ya que los objetos
representan entidades del mundo real dando una sensación mucho mejor del problema que un
conjunto de tablas. Además, es más potente, ya que es mucho más flexible y posee características
como polimorfismo. Por último, el modelo relacional se basa en el valor, mientras que el modelo de
objetos se basa en el principio de identidad.

4.1.1.14. Lenguaje de Datos

Los DBMS tradicionales existe un problema de concordancia entre los lenguajes de datos y
anfitriones, este problema se produce por diferencias en el paradigma de programación (Imperativo-
Java/ Declarativo-SQL) y de los tipos de datos. Los OODBMS han adoptado extensiones de LOO,
tanto para describir, como para manipular datos, esto a llevado a crear lenguajes “estilo SQL”.

El encapsulamiento es difícil de respetar en los OODBMS, considerándose los objetos como “cajas
grises” (ni negras, ni blancas).

En ocasiones, el lenguaje de datos se usa junto con el LP, por ejemplo, para la definición de los
servicios.

4.1.1.15. Arquitectura de tres niveles

En los OODBMS los esquemas externos (vistas) deben ocultar (o exponer) tanto los atributos como
los servicios, sin embargo, la mayoría de los productos no conceden a la arquitectura de tres niveles
gran importancia, descuidando sobre todo la definición de vistas.

4.1.1.16. Optimizador

En el caso de los OODBMS, sus lenguajes son navegacionales, por lo que la optimización resulta
difícil al ser el programador el que indica los caminos a seguir. A pesar de ello, en general, el
rendimiento de un OODBMS puede ser superior cuando se trata de navegar a través de objetos ya
cargados en memoria, siempre que se puede convertir fácilmente los IDO de los objetos a posiciones
de memoria.

El optimizador estará condicionado a las características que posean los lenguajes del OODBMS,
aunque la mayoría poseen optimizadotes rudimentarios, sin estadísticas en el DD que permitan una
mejor optimización.

4.1.1.17. Seguridad

Los OODBMS deben proporcionar todos los mecanismos necesarios para asegurar el control de la
confidencialidad, integridad y disponibilidad de la base de objetos.

4.1.1.18. Interfaces para Programas de Aplicación (API)

Unidad 4. Modelo Orientado a Objetos Página 14

Se deben ofrecer las interfaces necesarias para que programas escritos en distintos lenguajes
puedan acceder a los objetos de la base.

No es conveniente que esté estrechamente relacionado a un LP particular, aunque en la realidad, la

mayoría están muy unidos a un lenguaje específico, particularmente C++, Smalltalk y Java.

Diccionarios de datos

El OODBMS debe manipular metadatos sobre objetos, clases, jerarquías, colecciones, etc. con lo
que se obtiene mayor riqueza semántica que la de los DD relacionales.

4.1.1.19. Herramientas para desarrollo de aplicaciones

Es fundamental que posean distintos tipos de herramientas para desarrollo de aplicaciones, que van
desde lenguajes de desarrollo hasta navegadores que permiten una mejor manipulación de las
bibliotecas de clases. Esto todavía no se logra al nivel de los RDBMS.

4.1.1.20. Herramientas para la transformación de datos

Deben proporcionar herramientas que permitan transferir datos entre distintos DBMS, pudiéndose
volcar datos de un OODBMS a un RDBMS, o viceversa. Este tema es muy activo en este campo.

4.1.1.21. Utilidades para mantenimiento y mejora del rendimiento de la BD

También deben tener utilidades que permitan monitorizar el uso de recursos con el fin de aumentar el
rendimiento de los sistemas y realizar ajustes (tunning).

Actualmente, la mayoría ofrecen una capacidad limitada para ajustes de rendimiento parametrizado.

4.1.1.22. Soporte de datos multimedia

Deben soportar distintos tipos de datos, además de los formateados, como texto, imagen, voz, video.
En algunos OODBMS estos objetos se almacenan en BLOBs (Binary Large Objects), objetos de
almacenamiento masivo, que son colecciones de bits sin estructura interna.

4.1.1.23. Herramientas y Facilidades de Usuario

Deben proporcionar distintas interfaces a los usuarios, según sea la función que desempeñan en
cada momento (DBA, Programador, diseñador de clases, usuario final, etc.).

Las IGU también siguen el PaOO, facilitando la interacción del usuario con el sistema.

4.1.1.24. Distribución

Al igual que los RDBMS, cualquier elemento debe poder distribuirse en diferentes equipos de forma
transparente. El mayor problema es hacer coexistir los OODBMS y los RDBMS.
Unidad 4. Modelo Orientado a Objetos Página 15
4.1.1.25. Control de versiones y configuraciones

El control de versiones es una característica fundamental, debido a su uso en entornos de diseño

CAD/CAM y sistemas de información de oficinas, de modo que:

Todos los objetos persistentes tengan versiones y no exista un límite en el número de

versiones que puede tener.
Las aplicaciones deben poder acceder a la versión actual de un objeto o a cualquier otra.
Debe atenderse en especial a la eficiencia de las versiones actuales.

También es importante agrupar versiones compatibles de diversos objetos y tratarlos como una
unidad de más alto nivel.

Existen diversos enfoques para soportar versiones:

En el modelo de datos se incluyen una serie de primitiva que permiten tratar las versiones
como componentes fundamentales del propio modelo.
Las versiones no se consideran parte del modelo da datos en sí, pero se proporciona un
servicio de gestión de versiones mediante un nivel de software implementado sobre el
modelo básico.
Se considera la versión como una cuestión de las aplicaciones.
4.3. Estándar ODMG
En verano de 1991 Rick Cattell, de SunSoft, reunió a un grupo de expertos que trabajaban en
distintas empresas de OODBMS, y les propuso elaborar un estándar “de facto”, basado en las
características que presentaban los productos existentes y que se pudiera publicar en un breve plazo
de tiempo. Así nació el ODMG (Object Data Management Group) que reunía a los principales
vendedores de OODBMS: Object Design, Ontos, O2 Technology, Versant, Objectivity, POET
Software y Servio Corporation; y que contaba también con diversos revisores tanto de empresas,
como de universidades.

A mediados del 93 ya se había finalizado la primera versión de este estándar, determinando también
un conjunto de características a incluir en la segunda versión. Además ODMG propuso su estándar a
los organismos oficiales de normalización ANSI e ISO, así como al OMG (Object Management
Group).

La primera versión se publicó en 93, y se revisó en la edición 1.1 y 1.2. Las principales mejoras de la
versión 1.2 se referían al lenguaje de consulta de objetos (OQL, Object Query Language). La versión
2.0, además de algunas mejoras como la incorporación de nuevos tipos de colecciones, como el tipo
diccionario (dictionary type), introdujo la parte de la vinculación con el lenguaje Java. La versión
ODMG 3.0 incluye algunas mejoras de vinculación con Java, mejoras al modelo de objetos y algunas
correcciones y mejoras en las especificaciones del estándar.

Los principales componentes del estándar ODMG 3.0 son:

Modelo de objetos. El modelo de objetos está basado en el modelo de objetos de OMG y

se extiende, agregando componentes para soportar las necesidades específicas de las BD.
Lenguaje de Especificación de Objetos. El modelo de objetos ODMG soporta dos
lenguajes de especificación de objetos:

Unidad 4. Modelo Orientado a Objetos Página 16

 o ODL lenguaje de definición de objetos (Object Definition Language), que no es un
lenguaje de programación completo, aunque es un lenguaje de definición
independiente. Su sintaxis extiende al IDL, lenguaje de definición de interfaces
(Interface Definition Language) desarrollado por OMG.
o OIF. Una mejora que introdujo la versión 2.0 del estándar es la definición de otro
lenguaje de especificación, el formato de intercambio de objetos (OIF, Object
Interchange Format), que se puede usar para intercambiar objetos entre BD,
proporcionar documentación de BD o guiar un conjunto de pruebas de BD.
Lenguaje de Consulta de Objetos. Es un lenguaje declarativo (OQL, Object Query
Language) para consultar la BD, También proporciona algunos constructores para actualizar
los objetos de la BD. Aunque está basado en SQL, su semántica no es la misma. OQL
soporta capacidades más potentes con respecto al resultado de la consulta, permitiendo
obtener el mismo resultado en tipos de colecciones diferentes. Sin embargo, el resultado de
una consulta SQL siempre es una tabla.
Vinculación con Lenguajes de Programación. La versión 3.0 tiene enlaces con C++,
Java y Smalltalk. Estos enlaces definen la correspondencia entre ODL y los LP
correspondientes. También incluye una correspondencia del lenguaje de manipulación de
objetos (OML, Object Manipulation Language) para cada uno de los LP, para escribir código
portable que permita manipular los objetos persistentes usando uno de esos lenguajes.
Además incluye un mecanismo para invocar OQL y procedimientos para realizar
operaciones y transacciones sobre las BD de objetos.
4.3.1. Ejemplos
Declaración de clases (ODL)
class Persona //nombre de la clase (intención)
(extent gente key idP) { //nombre del archivo que contiene los datos (extensión)
//si no se indica extent es interface
//y opcional llave candidata del objeto(OID es automático)
attribute idP int; //atributo atómico (int, real, char, string, boolean, enum)
attribute nombre string;
attribute Struct Direc(string calle, string ciudad, dtring estado, string cp) direccion;
//atributo tipo estructurado (struct, set, list, array, bag,
// dictionary), se puede usar después como
// Persona::Direc
attribute telefono string;
string getNombre(); //método, sólo la firma, implementación en LP anfitrión,
//los parámetros pueden ser IN, OUT ó IN/OUT
//puede usar self
//pueden sobrecargarse y sobrescribirse
void setNombre(string nuevoNombre);
};
class Estudiante extends Persona //nombre de clase que hereda de Persona
(extent estudiantes) {
attribute creditos int;
int getCreditos();
void addCreditos(int numCreditos);
relationship Set(<Grupo> tomaClase Inverse Grupo::tieneEstudiantes;
//relación Estudiante toma un conjunto de clases en unGrupo
//y su inversa Grupo tieneEstudiantse Estudiante (M:M)
}
class Profesor extends Persona (extent prof) {
attribute enum NivelProf {instructor, asistente, asociado, académico} nivel;
//atributo enumerado
Unidad 4. Modelo Orientado a Objetos Página 17
 attribute salario real(8,2);
string getNivel();
real getSalario();
relationship Departamento perteneceA Inverse Departamento::tieneProfesor;
//relación bidireccional Profesor perteneceA un Depto
/y su /inversa Departamento tieneProfesor Profesor (1:M)
relationship Set<Grupo> daClaseEn Inverse Grupo::tieneProfesor;
//relación Profesor daClase en un conjunto de Grupo
//y su inversa Grupo tieneProfesor profesor
}
class Grupo (extent grupos) {
attribute grupo string;
relationship Set<Estudiante> tieneEstudiantes Inverse Estudiante::tomaClase;
relationship Profesor tieneProfesor Inverse Profesor::daClaseEn;
}

Consultas (OQL)
Select e.idP, e.creditos //muestra todos los id y créditos en el archivo(extent) estudiantes
From estudiantes e;

Select g.getNombre() //muestra los nombres de todas las personas en extent gente
From g in gente; //otra forma de alias

Select e.idP, e.tomaClase //obtiene el conjunto de objetos relacionados al objeto

From estudiantes as e //mediante la relación e.tomaclase, muestra todas las
Where e.idP = ‘E999’; //clases que toma el estudiante E999

Select p.nombre //encuentra registros por su referencia (d–var iterador)

From departamentos as d, d.tieneProfesor as p //muestra los profesores del
Where d.nomDepto = ‘Biología’ //departamento de Biología
Order By p.nombre; //ordenador por nombre

Select p.nombre //misma consulta, usando subquery, obtiene todos los

From (Select d //departamentos referenciados por el iterador b y
From d in departamentos //por cada b obtiene un iterador p
Where d.nomDepto = ‘Biología’) as b,
b.tieneProfesor as p
Order By p.nombre;

Avg(Select p.salario //obtiene el promedio de salarios de profesores que

From prof as p //pertenecen al departamento de historia
Where p.perteneceA = ‘Historia’);

Select g //encuentra los grupos que tengan más de 30 estudiantes

From grupos as g
Where count(g.tieneEstudiantes > 30);

Tarea.
a. Leer al menos 2 fuentes adicionales sobre los temas vistos en esta unidad y hacer un resumen
de la unidad (máximo 1 cuartilla). No olvidar conclusiones y bibliografía.
b. Explicar cuáles son las diferencias entre una DBMS y un OODBMS, entre OID y llave primaria,
entre BDOR y BDOO, entre SQL y OQL.

Unidad 4. Modelo Orientado a Objetos Página 18