Semana 01

Ing.
de Sistemas UPP BDOO
SISTEMAS MANEJADORES
DE BASES DE DATOS
ORIENTADAS A OBJETOS
(SMBDOO)
Ing. de Sistemas UPP BDOO
INTRODUCCIÓN A LOS
SISTEMAS DE BASES DE
DATOS OO (SBDOO)
INTRODUCCIÓN
• Hace algunos años, la creación de nuevas aplicaciones

requerían de una difícil selección de información para
muchas fuentes.
• Los programas eran dependientes de las estructuras de los
datos almacenados, haciendo estas estructuras difíciles al
cambio.
• Sin embargo, los Sistemas de BD (SBD) han mejorado los
procesos de desarrollo de aplicación en grandes ambientes
de datos intensivos, proporcionando una sencilla y
uniforme vista de datos expresada en términos de
estructuras independientes.
INTRODUCCIÓN
• Su alto nivel de características lingüísticas y sus

facilidades para compartir información de una manera
controlada, hace posible que se puedan crear aplicaciones
integradas más fácilmente.
• La integridad de los datos está controlada por el SBD.
• Es decir, el SBD debe ser responsable de cada programa

de aplicación, dentro de la BD.
• Existe un conjunto de rutinas que facilitan el formateo de

datos y accesos a los mismos.
INTRODUCCIÓN
• En la década pasada se generó mucho interés sobre los

SBDOO.
• Estos sistemas tienen su origen en los lenguajes de POO.
• Donde los usuario no tienen que luchar contra las

construcciones orientadas a la máquina (p. e. campos,
atributos, etc).
• Sino que en su lugar deben tener la posibilidad de manejar

objetos y operaciones sobre esos objetos, que se asemejan
mucho más a sus contrapartes en la realidad.
INTRODUCCIÓN
• En otras palabras, la idea fundamental es elevar el nivel

de abstracción.
• Elevar el nivel de abstracción es incuestionablemente un

objetivo valioso y el paradigma de objetos ha tenido
mucho éxito para satisfacer ese objetivo.
• La pregunta sería: Si el paradigma de la POO también

puede ser aplicado satisfactoriamente en las BD.
INTRODUCCIÓN
• La idea de manejar una BD que está compuesta de

“objetos complejos”, en lugar de tener que manejar
atributos, inserción de tuplas y claves externas, etc., es
obviamente más atractiva desde el punto de vista del
usuario.
• Aunque las disciplinas de los lenguajes de Programación

y la Administración de BD tienen mucho en común,
también difieren en determinados aspectos:
• Un programa de aplicación está hecho, por definición, para

resolver algún problema específico.
INTRODUCCIÓN
• Por el contrario, una BD está hecha para resolver una variedad de

problemas diferentes, y algunos de ellos ni siquiera son
conocidos el momento de establecer las BD.
• Mucha gente cree que los Sistemas de Objetos

representan un gran salto hacia delante en la tecnología de
BD.
• Creen que las técnicas de objetos son el enfoque a escoger

para las áreas de aplicaciones “complejas”.
• Actualmente, los sistemas de software han puesto un

ambiente típico, incluyen herramientas, editores de
esquema, verificadores de diseño y programas de
circuito disponibles, y todo integrado.
• La disponibilidad de alta ejecución en las estaciones

de trabajo gráfica, se han incrementado tanto en la
expansión como en la complejidad de las aplicaciones
de los datos intensivos.
• Algunos ejemplos son:

 Diseño y Manufactura Asistido por Computadora
(CAD/CAM)
 Ingeniería de Software Asistida por Computadora (CASE).
 Sistemas de Información de Oficinas (OIS).

 Manufactura Interada por Computadora (CIM).
 Sistema de Información Geográfica (GIS).
 Ciencia y Medicina.
• Todas éstas son áreas en las que los productos SQL

clásicos tienden a incurrir en problemas.
• Sin embargo, a lo largo de los años han sido

publicados muchos artículos técnicos sobre estos
temas y más recientemente, han entrado al mercado
varios productos comerciales.
• Pero el problema continúa, sobre todo en nuevas

herramientas, que utilizan subsistemas que requieren
de muchos números de datos persistentes.
• Donde el nivel de complejidad de estos programas y

de los datos, han llegado más allá de la capacidad de
los SBD tradicionales.
• Actualmente los programas de aplicación, en

ambientes de diseño, almacenan sus datos en
estructuras de archivos de aplicación específica.
• Aquí el estado del arte es difícil, como en la misma

etapa que existió después de introducir la tecnología
de BD.
• El desarrollo de las Bases de Datos Orientadas a

Objetos (BDOO), con una gran cobertura, han surgido
por esta necesidad.
• Además combina las mejores cualidades de los

archivos planos, las bases jerárquicas y relacionales.
• Las BDOO representan el siguiente paso (?) en la

evolución de las BD para soportar el análisis, diseño y
Programación Orientada a Objetos (POO).
• Estás permiten el desarrollo y mantenimiento de

aplicaciones complejas, ya que se puede utilizar un
mismo modelo conceptual y así aplicarlo al análisis,
diseño y programación.
• Reduciendo el problema entre los diferentes modelos

a través de todo el ciclo de vida, con un costo
significativamente menor.
• Como cualquier BD programable, una BDOO da un

ambiente para el desarrollo de aplicaciones con un
depósito persistente listo para su explotación.
• Permiten que el mismo modelo conceptual se aplique

al análisis, diseño, programación, definición y acceso
a la BD.
• Esto reduce el problema del operador de traducción

entre los diferentes modelos a través de todo el ciclo
de vida.
• El modelo conceptual debe ser la base de las

herramientas CASE OO totalmente integradas, las
cuales ayudan a generar la estructura de datos y los
métodos.
• Además las BDOO ofrecen un mejor rendimiento en

las máquinas que las BD por relación, para
aplicaciones o clases con estructuras complejas de
datos.
• Sin embargo, las BDOO coexistirán con las BD

Relacionales, como una forma de estructura de datos
dentro de una BDOO.
ANTECEDENTES
• El propósito de los Sistemas de Bases de Datos (SBD) es

la gestión de grandes cantidades de información.
• Las primeras BD surgieron del desarrollo de los sistemas

de gestión de archivos.
• Estos sistemas primero evolucionaron en BD de Red o en

BD Jerárquicas y, más tarde, en BD Relacionales.
• Las aplicaciones de BD tradicionales consisten en tareas

de procesamiento de datos, tales como servicios bancarios
y la gestión de nómina.
• Tales aplicaciones presentan conceptualmente tipos de

datos simples.
• Los elementos de datos básicos son registros bastante

pequeños y cuyos campos son atómicos.
• Es decir, estos campos no contienen estructuras

adicionales y en los que se cumple la primera forma
normal.
• Las BD Relacionales (BDR) almacenan los datos en

forma de tablas, renglones y columnas.
• De tal manera, la BDR no son adecuadas para almacenar

objetos, ya que pueden contener estructuras complejas de
elementos de datos y también apuntadores a otros objetos.
• Además, los objetos incluyen instrucciones ejecutables, o

métodos, y para hacer persistentes a los objetos también
deben proporcionar ciertos medios para almacenarlos.
• Los SMBDOO, se desarrollaron a principios de la década

de los 90s para proporcionar un almacenamiento de
objetos persistentes.
• Sin embargo estos productos no se han comercializado

con éxito debido a que necesitan convertir los datos al
formato MDOO.
• Las organizaciones no realizan esta conversión porque es

muy costosa y las ganancias no compensan la inversión.
• En respuesta a esto, los proveedores de los DBMS

tradicionales están aumentando las capacidades de sus
productos para permitir el almacenamiento de objetos.
• Así como también, el almacenamiento tradicional de datos

relacionales.
• A tales productos se les llama SMBD de Objeto/

Relacionales, y probablemente su uso aumentará en los
próximos años.
• En particular Oracle, ha desarrollado diversos recursos

para la modelación y almacenamiento de objetos.
• Existen dos estándares importantes de objetos: El SQL3 y

el ODMG-93
• Las aplicaciones de las BD en áreas como el Diseño

Asistido por Computadora, la Ingeniería de Software y el
Procesamiento de Documentos no se ajustan al conjunto
de suposiciones que se hacen para aplicaciones del estilo
de procesamiento de datos.
• El Modelo de Datos Orientado a Objetos (MDOO) se ha

propuesto para tratar algunos de estos nuevos tipos de
aplicaciones.
• El MDOO es una adaptación a los SBD tradicionales.

• El enfoque OO para la programación fue introducida por

primera vez con el lenguaje Simula 67.
• Que se diseñó para la programación de simulación.
• Smalltalk fue uno de los primeros lenguajes de

Programación OO (POO) para aplicaciones generales.
• Actualmente, los lenguajes Java y C++ son los lenguajes

de POO más usados.
• La POO se basa en el concepto de encapsulamiento de

datos y código que opera sobre éstos en un objeto.
 La ventaja de la encapsulación es que permite que la

representación interna de los objetos, sea cambiada sin necesidad
de que las aplicaciones que los usan tengan que ser reescritas.
 La encapsulación implica la Independencia Física de los Datos.
 Los objetos encapsulados son descritos por:
 Una Memoria Privada (Miembros o Atributos).
 Interfaz Pública (Métodos).

• Los objetos estructurados se agrupan en clases.
• El conjunto de clases está estructurado en sub y

superclases, basado en una extensión del concepto ISA
del modelo Entidad - Relación.
• Puesto que el valor de un dato en un objeto, también

puede ser un objeto, es posible representar el contenido
del objeto dando como resultado un objeto compuesto.
PRINCIPIOS DE OO
PRINCIPIOS DE ORIENTACIÓN A OBJETOS
• Es conveniente aclarar que muchos conceptos de

objetos (o definiciones de éstos) son bastante
imprecisos y hay muy poco consenso verdadero y
mucho desacuerdo, incluso en el nivel más básico.
• En particular, no hay un “Modelo de datos de objetos”

abstracto ni formalmente definido.
• En una BDOO, cualquier cosa es un objeto y se

manipula como tal.
• Un Objeto es una instancia que responde a mensajes

activando un método.
 La estructura interna no es visible para los usuarios de ese
objeto.
• Los sistemas OO proporcionan el concepto de

Identificador del Objeto (OID) para identificar a los
objetos.
• Los identificadores de los objetos son únicos.
• Cada objeto tiene un solo identificador y no hay dos

objetos que tengan el mismo identificador.
• Generalmente el identificador lo genera el sistema de

manera automática.
• A diferencia de las BD relacionales donde un valor de

dato único, se genera de manera externa al sistema.
• Hay muchas situaciones en las que hacer que el

sistema genere identificadores de manera automática
resulta una ventaja.
• Dado que libera a los seres humanos de llevar a cabo

esa tarea.
• Sin embargo, esta característica debe manejarse con

precaución.
• Los identificadores generados por el sistema suelen

ser específicos el mismo.
• Si se desplazan los datos a un sistema de BD

diferente, hay que traducirlos.
• Además, los identificadores generados por el sistema
pueden resultar redundantes, si las entidades que se
modelan ya disponen de identificadores unívocos
externos al sistema.
• Por lo general, los SMBDR se apoyan en claves definidas y
controladas por el usuario (claves de usuario), para efectos
de identificación y referencia de entidades.
• En realidad los apuntadores estilo OID están expresamente

prohibidos en las BDR.

• Los objetos soportan una serie de características:
• Se agrupan en tipos denominados clases.
• Contienen datos internos que definen su estado actual.
• Soportan ocultación de datos.
• Pueden heredar propiedades de otros objetos.
• Pueden comunicarse con otros objetos enviando o pasando

mensajes.
• Tienen métodos que definen su comportamiento.

• Las clases son una colección de objetos con

propiedades similares, compartimiento común,
relaciones comunes a otras clases.
• La instancia es un objeto con propiedades definidas

en su descripción de la clase.
• El mensaje es una clase que debe tener un método

correspondiente. Un mensaje puede ser enviado a un
objeto a ejecutar una acción.
• El método es una lista de instrucciones detalladas que

definen cómo responde un objeto a un mensaje en
particular.
• La superclase es la clase que deriva a otra clase.
• La subclase es la clase derivada de una superclase.
• La liga expresa compatibilidad de relaciones entre las

clases.
• Los objetos heredan las características de su clase y de

todas las clases de nivel superior a la que pertenecen.
• Estos principios y técnicas hacen que las BDOO estén

adecuadas a aplicaciones que implican tipos de datos
complejos.
• Tipos de datos complejos, tales como documentos

compuestos o de diseño asistidos por computadora
que combinan texto, gráficos y hojas de cálculo.
• La BD proporciona un modo natural de representar las

jerarquías que aparecen en los datos complejos.
• La jerarquía de clases permite a la BD seguir la pista

del tipo de cada objeto en el documento.
• Finalmente, el mecanismo de mensajes ofrece soporte

natural para una interfaz de usuario gráfica.
BASES DE DATOS ORIENTADAS A OBJETOS (BDOO)
• El campo de las BDOO se ha introducido como una

nueva área de investigación.
• Los campos de Lenguajes de Programación,

Inteligencia Artificial e Ingeniería de Software han
contribuido con el uso de la tecnología OO en el área
de las BD.
• El desafío del área de BD es integrarlos en un diseño

de sistema simple que mantenga el equipo deseado
para cada campo.
• El resultado es conservar las características centrales

de las BD modernas, incluyendo:
• Persistencia
• Control de Concurrencia
• Recuperación
• Consistencia
• Lenguaje de Consulta.
• Desde el punto de vista del desarrollador las ventajas

están dadas en ganancias de productividad, dado su
modelado más simple que facilita el desarrollo de
aplicaciones.
• El modelado de aplicaciones es mucho más sencillo

gracias al concepto de objetos complejos y el modelo
obtenido es fácilmente comprensible para el usuario.
• Este modelo puede ser validado directamente por el

cliente de la aplicación.
• El enfoque OO favorece la reutilización.
• Porque gracias al encapsulamiento y a la herencia, es

fácil especializar un componente existente para
responder a las necesidades particulares de la
aplicación.
• Desde el punto de vista del usuario final, los

SMBDOO, proporcionan mayor aporte en la calidad
en términos de ergonomía, fiabilidad, evolución y
desempeño.
ESTRUCTURA DE OBJETOS
• El Modelo Orientado a Objetos (MOO) se basa en

encapsular código y datos en una única unidad,
llamada objeto.
• La interfaz entre un objeto y el resto del sistema se
define mediante un conjunto de mensajes.
• El término mensaje en un contexto orientado a
objetos, no implica el uso de un mensaje físico en una
red de computadoras.
• Si no que se refiere al paso de solicitudes entre objetos
sin tener en cuenta detalles específicos de
implementación.
• La capacidad de modificar la definición de un objeto

sin afectar al resto del sistema, está considerada como
una de las mayores ventajas del modelo de POO.
JERARQUÍA DE CLASES.
• En una BD existen objetos que responden a los
mismos mensajes, utilizan los mismos métodos y
tienen variables del mismo nombre y tipo.
• Sería inútil definir cada uno de estos objetos por

separado por lo tanto se agrupan los objetos similares
para que formen una clase, a cada uno de estos objetos
se le llama instancia de su clase.
• Todos los objetos de su clase comparten una

definición común, aunque difieran en los valores
asignados a las variables.
• Así que básicamente las BDOO tienen la finalidad de

agrupar aquellos elementos que sean semejantes en las
entidades para formar una clase, dejando por separado
aquellas que no lo son.
• Por ejemplo: Tomemos como referencia la entidad

Alumno y la entidad Maestro.
• Donde los atributos considerados para cada uno, son

en Alumno:
• Nombre
• Dirección
• Teléfono
• Especialidad
• Semestre
• Grupo
Maestro:
• Nombre
• Dirección
• Teléfono
• Número económico
• Plaza
• RFC
• Los atributos de Nombre, Dirección y Teléfono se

repiten en la entidad Alumno y Maestro, así que
podemos agrupar estos elementos para formar la clase
Persona, con dichos campos.
• Quedando por separado en Alumno:
• Especialidad
• Semestre
• Grupo.
• Y en Maestro:
• Número Económico
• Plaza
• RFC.
CLASE PERSONA
Nombre
Dirección
Teléfono
HERENCIA
SUPERCLASE
SUBCLASES
Especialidad Número
Semestre Económico
Grupo Plaza
RFC
CLASE ALUMNO CLASE MAESTRO

PROBLEMAS A
RESOLVER POR LOS
SMBDOO
• Un programa de datos intensivo es aquel que produce

y/o requiere de un gran número de datos (muchos de
ellos no podrían introducirse al mismo tiempo dentro
de la memoria virtual de un programa).
• Programar a lo grande se refiere a que los procesos de

Ingeniería de Software requieran de múltiples
programadores para producir programas grandes y
complejos.
• La complejidad de estos sistemas no sólo se muestra

en los programas que manipulan datos sino en los
datos mismos.
• Por ejemplo: Los datos que son usados en la

aplicación de diseños eléctricos contienen muchas
interconexiones complejas, con muchas limitaciones
complejas en la forma de que éstas son usadas.
• Un circuito usa muchos componentes de diferentes

tipos, y éstos tienen que hacer referencia a otros
componentes a los que están conectados.
• Un problema en el desarrollo de aplicaciones en las

BD es la incompatibilidad entre el Lenguaje de
Manipulación de Datos (DML) de las BD, y el
Lenguaje de Programación de Propósito General, en el
cual el resto de las aplicaciones son escritas.
• En los sistema OO, se utiliza un Lenguaje Integrado

para las operaciones de BD y para las que no lo son.
• El lenguaje anfitrión y el lenguaje de BD están

fuertemente acoplados en estos sistemas, de hecho
son los mismos. A diferencia del SQL.
• Una ventaja importante es que permite una mejor

verificación de tipo.
• Se dice que en este lenguaje unificado no hay

desacoplo de impedancia entre un lenguaje de
programación procedural y el lenguaje de
manipulación de datos.
• Donde desacoplo de impedancia se refiere a la

diferencia entre el nivel de registro (manejado por un
lenguaje de programación) y el nivel de conjunto
(como la hace SQL).
• De hecho los lenguajes de objetos están en el nivel de

registros (o procedimientos).
• Son lenguajes “3GL”, no manejan conjuntos sólo

procedimientos.
• El rendimiento queda en gran parte en manos de los

usuarios (programadores o el ASBD).
• Los Lenguajes de Programación de BD resuelven el

problema de incompatibilidad, documentando los
tipos de datos de un Lenguaje de Propósito General
persistente, o agregando tipos de sistemas de un
lenguaje.
• Sin embargo, cuando se accesan a los datos de otros

lenguajes, el problema de la incompatibilidad
realmente existe.
• Las BDOO tratan de mejorar el problema de la

incompatibilidad, extendiendo el DML.
• Sin embargo, pocas BDOO pueden expresar las

aplicaciones complejas por sí mismas.
• El DML carece de una manipulación de datos de la

Aplicación.
• El lenguaje de propósito general tiene persistencia de

datos sólo en la forma de los archivos.
• Careciendo de un modo sofisticado de memoria

persistente que incluye tipos de alto nivel,
limitaciones y consultas.
• Para preservar la exactitud de las BD en la ejecución

de procesos concurrentes, los sistemas de BD definen
el concepto de Transacciones Atómicas.
• Las transacciones son unidades de trabajo que se

permiten procesar de manera concurrente,
garantizando resultados que son equivalentes a los
resultados producidos por algunas ejecuciones
seriales.
• Definimos esta propiedad de equivalencia como

Seriabilidad.
• Existen muchas implementaciones que garantizan las

ejecuciones seriabilizables, en las transacciones de
Read-Write.
• Si existen transacciones de Read y Write al mismo

tiempo sobre el dato x, entonces surgirá un conflicto al
escribir el dato x, por lo que el manejador de datos
tomará la decisión correspondiente.
• Las BDOO presentan una oportunidad para dar más

concurrencia que otros enfoques tradicionales.
• En el enfoque OO, los sistemas de BD conocen acerca

de las operaciones que van a ser ejecutadas.
• Para aplicaciones cooperativas, como en el diseño de

ambientes, la noción de seriabilidad es muy exacto.
• El diseño cooperativo está basado en la noción de

unidades de trabajo, que puedan interactuar como
resultados inesperados.
• Esta observación ha creado una nueva área de interés

de investigación, basada en la Tecnología OO en el
control de concurrencia.
• Por ejemplo, es muy común ver las BDOO

implementadas como un interprete de un manejador
de almacenamiento.
• Este es el responsable de los movimientos de los
objetos desde el disco hacia la memoria principal, para
el manejador del Buffer y algunas transacciones de
bajo nivel y tareas de recuperación.
• El interprete es el responsable de proveer las

facilidades requeridas en las vistas de objetos, tipos y
métodos.
• Esta arquitectura aparece en los sistemas de BD
Relacionales.
• Existen varias BD comerciales OO actualmente bajo

desarrollo, pero sólo un grupo de ellas están
disponibles hoy en día como productos comerciales.
• Sin embargo, las BDOO ya han provocado una

tormenta de controversias en la comunidad de las BD.
• Los lenguajes de consultas para BDOO son aún

difíciles de implementar.
• Existe una tensión entre encapsulación y la vista

estructural de datos característicos de lenguajes de
consulta tales como: SQL y QUEL.
• Una BDOO debe tener por lo mismo los siguientes

requerimientos:
• Debe proporcionar funcionalidad en la BD.
• Incluir todas las características esenciales.
• Debe soportar la Identificación de Objetos (OID).
• Debe proporcionar Encapsulamiento. Esta encapsulación

puede ser la base por la cual todos los objetos abstractos son
definidos.
• Debe soportar objetos con estado complejo. El estado de un

objeto puede referirse a otros objetos.
HERENCIA.
• Las clases en un Sistema OO se representan en forma

jerárquica.
• Así que las propiedades o características de un

elemento, las contendrán (o heredarán) los elementos
que de ésta se deriven.
• Decimos por lo tanto que las entidades derivadas son

subclases de la clase padre o Superclase.
• Se pueden crear muchas agrupaciones (clases) para

simplificar un modelo.
CONSULTAS ORIENTADAS A OBJETOS.
• Los lenguajes de POO, requieren que toda la

interacción con objetos se realice mediante el envío de
mensajes.
• El término mensaje en un entorno OO no implica el uso de

mensajes físicos en la red.
• Por el contrario hace referencia al intercambio de solicitudes

entre los objetos.
• Se utiliza a veces la expresión invocar a un método para

denotar el hecho de enviar un mensaje a un objeto y la
ejecución del método correspondiente.
CONSULTAS ORIENTADAS A OBJETOS.

• Dado que la única interfaz externa presentada por cada
objeto es el conjunto de mensajes a los que responde, resulta
posible modificar las definiciones de los métodos y de las
variables sin afectar al resto del sistema.
• La posibilidad de modificar la definición de un objeto sin
afectar al resto del sistema se considera una de las mayores
ventajas del paradigma de la POO.
• Consideremos un ejemplo con una entidad Alumno, y

deseamos que la consulta realice la búsqueda de todos
los alumnos que cursan la materia de Base de Datos II.
• Para realizar esta consulta, se tendría que enviar un
mensaje a cada instancia Alumno dentro del sistema.
• Generalmente en una BD hay muchos objetos

similares.
• Por similar se entiende que responden a los mismos

mensajes, utilizan los mismos métodos y tienen
variables del mismo nombre y del mismo tipo.
• Así un lenguaje de consultas para un sistema de

BDOO, debe incluir tanto el modelo de pasar el
mensaje de objeto a objeto, como el modelo de pasar
el mensaje de conjunto en conjunto.
Ejemplo del lenguaje para Manipulación de objetos C++ de ODMG

int crear_titular_cuenta(String nombre, String direccion{
d_Database bd_banco_obj;
d_Database * bd_banco = &bd_banco_obj;
bd_banco->open(“BD-Banco”);
d_Transacction Trans;
Trans.begin();
d_Ref<Cuenta> cuenta = new(bd_banco, “Cuenta”)Cuenta;
d_Ref<Cliente> clien = new(bd_banco, “Cliente”)Cliente;
clien->nombre = nombre;
clien->dirección = dirección;
clien->cuentas.insert_element(cuenta);
cuenta->titulares.insert_element(clien);
…..
Trans.commit();
Bd_banco->close();
}
COMPLEJIDAD DE MODIFICACIÓN.
• En las BDOO pueden existir los siguientes cambios:
• Adición de una nueva clase: Para realizar este proceso, la nueva

clase debe colocarse en la jerarquía de clase o subclase, cuidando
las variables o métodos de herencia correspondientes.
• Eliminación de una clase: Se requiere la realización de varias

operaciones, se debe de cuidar los elementos que se han heredado
de esa clase a otras y reestructurar la jerarquía.
• En sí la estructuración de modelos OO simplifica la

estructura, evitando elementos o variables repetidas en
diversas entidades.
COMPLEJIDAD DE MODIFICACIÓN.
• Sin embargo el precio de esto es dedicarle un

minucioso cuidado a las relaciones entre las clases
cuando el modelo es complejo.
• La dificultad del manejo de objetos radica en la

complejidad de las modificaciones y eliminaciones de
clases.
• Ya que de tener variables que heredan de otros

objetos, se tiene que realizar una reestructuración que
involucra una serie de pasos complejos.
PROGRAMACIÓN ORIENTADA A OBJETOS.
• POO (Object-Oriented Programming).
• Muchas organizaciones que actualmente usan tecnología

orientada a objetos también desean los beneficios de los
SMBDOO.
• En otras palabras, se desea la migración de BD y

aplicaciones de BD Relacionales a OO.
• La migración a la tecnología de objetos consiste de la

ingeniería reversa de los programas de aplicación y la
migración de la BD.
• El objetivo de la migración de la BD es tener un esquema

equivalente y la BD disponibles bajo los nuevos
SMBDOO.
• Esto desde luego puede ser logrado por medio de la

transformación manual del código de los programas lo
cual resulta demasiado complicado.
• Para esto existen tres enfoque que hacen uso de la

tecnología de objetos para BD Relacionales (BDR).
 Construir una interface OO sobre el Sistema de BDR.
 La migración a un SBD Objetos/Relacional.
 Conversión del esquema de BDR a uno OO.


Construir una interface OO sobre el Sistema de BDR.
• El primer enfoque retiene la BDR y crea una interface OO
encima de ésta.
• Este enfoque es el más fácil.
• No existe interrupción del sistema para la migración de

datos y no existe pérdida semántica de la información.
• Por otro lado el rendimiento disminuye debido que no

existe un buen acoplamiento entre los dos paradigmas en
el tiempo de ejecución.
La migración a un SBD Objetos/Relacional.
• En el segundo enfoque, los datos deben ser migrados de

acuerdo con el SMBD (por ejemplo Oracle 7 a 8).
• Y las características Orientadas a Objetos sólo pueden ser

explotadas con la modificación o extensión del esquema.

Conversión del esquema de BDR a uno OO.
• El tercer enfoque es la migración de la base de datos en
donde un nuevo esquema bajo el SMBDOO es creado.
• Y los datos son migrados de la Base de Datos Relacional
a la Orientada a Objetos.
• Cada uno de los tres enfoques anteriores tiene sus

ventajas y desventajas.
• Especialmente el tercero, una metodología y herramientas

de soporte son críticas para una migración exitosa.
DISEÑO DE DISTRIBUCIÓN
DE OBJETOS
DISTRIBUCIÓN DE OBJETOS.
• Dos aspectos importantes del diseño de distribución son:

La Fragmentación y la Colocación.
• El diseño de la distribución en el mundo de objetos trae

nuevas complejidades, debido al encapsulamiento de
métodos junto con los estados de los objetos.
• Un problema es que los métodos están implementados y

compartidos por todas las instancias de objetos de ese
tipo.
• Se tiene que decidir si la fragmentación se realiza
solamente sobre los atributos, duplicando los métodos en
cada fragmento.
• O si los métodos se puedan fragmentar.
• Hay que recordar que algunos dominios de algunos

atributos pueden ser clases.
• Por lo que la fragmentación de clases con respecto a tales

atributos puede afectar en otras clases.
• Y si la fragmentación se lleva a cabo con respecto a los
métodos, es necesario distinguir entre métodos simples y
métodos compuestos.
 Métodos Simples son aquellos que no invocan a otros métodos.

 Mientras que los Complejos invocan métodos de otras clases.
PARTICIONAMIENTO DE CLASE HORIZONTAL
• Comencemos con una fragmentación de una clase con

métodos y atributos simples.
PARTICIONAMIENTO DE CLASE HORIZONTAL
• Para este caso, el particionamiento horizontal primario se

puede lograr de acuerdo a un predicado definido en un
atributo de la clase.
• Donde cada clase (o subclase) derivada satisface el

predicado de particionamiento particular de la clase
original.
• Si estos predicados son mutuamente exclusivos, entonces

las instancias de la clases son disjuntos.
PARTICIONAMIENTO DE CLASE VERTICAL
• La fragmentación vertical es considerablemente más

compleja.
• Por ejemplo al fragmentar una clase verticalmente

produce un número de clases (o subclases), cada una
conteniendo algunos atributos y métodos.
• Por lo que cada uno de los fragmentos tiene menos

definiciones que la clase original.
PARTICIONAMIENTO DE CLASE VERTICAL
• Si los métodos son simples, entonces los métodos pueden

particionarse fácilmente.
• Y cuando no son simples, la ubicación de estos métodos

llega a ser un verdadero problema.
COLOCACIÓN DE OBJETOS.
• El problema de la colocación de datos, para las BDOO,
involucra la ubicación de métodos y clases.
• Y como las aplicaciones de las BDOO invocan métodos,

la ubicación de éstos afecta el rendimiento de las
aplicaciones.
• La colocación de métodos los cuales necesitan accesar

múltiples clases en diferentes sitios, es un problema el
cual aún no ha sido abordado.
• Existen cuatro alternativas para la colocación de objetos.

1. Comportamiento Local – Objeto Local. Tanto el
comportamiento (método) del objeto, como los
argumentos se encuentran de manera local.
2. Comportamiento Local – Objeto Remoto. En este caso

el comportamiento y el objeto al cual se le aplica, están
localizados en diferentes sitios.
 Una alternativa consiste en mover el objeto remoto al sitio donde

el comportamiento se localiza.
 Otra es enviar la implementación del comportamiento al sitio
donde reside el objeto.
3. Comportamiento Remoto – Objeto Local. Es el caso
inverso del punto 2.
4. Función Remota – Argumento Remoto. Caso inverso

del punto 1.
REPLICACIÓN
• La replicación agrega una nueva dimensión al problema
del diseño.
• Objetos, Clases de Objetos, o Colecciones de Objetos ( o

todo) pueden ser replicados.
ARQUITECTURA DE UNA
BDOO
ARQUITECTURA.
• Una manera de desarrollar un sistema distribuido es la de
Cliente/Servidor.
• La mayoría de los actuales SMBDOO son sistemas

cliente/servidor.
• Donde el cliente solicita “objetos” del servidor.
• Y el servidor los obtiene de la BD y los regresa al cliente

solicitante.
• Estos sistemas son llamados Servidor de Objetos.

ARQUITECTURA DE UNA BDOO.

En la siguiente se muestran algunos de los principales
productos de BDOO y sus vendedores.
PRODUCTO PROVEEDOR
Gemstone Servio Corporation, Alameda,CA

Itasca Itasca Systems,Inc.,Minneapolis,MN
Objectivity Objectivity,Menlo Park,Ca
Object Store Object Design,Inc.,Burlington,MA
Ontos Ontos Inc.,Bellerica,MA
Versant Versant Object Technology,Menlo Park,CA
Seis Productos de BDOO y sus Proveedores.

Arquitectura de una BDOO
• Los primeros se diseñaron como una extensión de los

lenguajes de programación como Smalltalk ó C++.
 Por ejemplo el sistema GemStone y su lenguaje OPAL, están

basados en Smalltalk, uno de los lenguajes de objetos más puros.
 Aunque recientemente los lenguajes de objetos más importantes

son Java y C++ en ese orden, que han desplazado a otros.
 A pesar del hecho de que estos dos son menos “puros” que
smalltalk.
Arquitectura de una BDOO
• El DML (Lenguaje para La Manipulación de Datos) y el

DDL (Lenguaje para la Definición de los Datos)
constituyen un lenguaje OO común.
• El diseño de las BDOO actuales deben aprovechar al

máximo las características del CASE, e incorporar
métodos creados con cualquier técnica poderosa.
Desarrollo con Bases de Datos OO
• Las BDOO se desarrollan al describir, en primer lugar, los

tipos de objetos importantes del dominio.
• Estos tipos de objetos determinan las clases que

conformarán la definición de la BDOO.
• Por ejemplo: Una BD diseñada para almacenar la

geometría de ciertas partes mecánicas incluiría clases
como CILINDRO, ESFERA y CUBO.
• El comportamiento de CILINDRO podría incluir

información relativa a sus dimensiones, volumen, área,
etc.:
• Clase de CILINDRO{
ALTURA FLOTANTE ();
RADIO FLOTANTE ();
VOLUMEN FLOTANTE ();
AREA FLOTANTE ();
};
• Se puede llegar a definiciones similares para el cubo y la

esfera.
• En la definición anterior, ALTURA, RADIO y ÁREA

representan los mensajes que se pueden enviar a un objeto
CILINDRO.
• La Implantación se lleva a cabo en el mismo lenguaje,

escribiendo funciones correspondientes a las solicitudes
OO:
CILINDRO::ALTURA ( ) {RETORNA CILINDRO_ALTURA;}

CILINDRO::VOLUMEN ( ) {RETORNA PI * RADIO ( ) * ALTURA ( ) ;}
• En este caso, la Altura se almacena como un elemento de

los datos, mientras que Volumen se calcula mediante la
fórmula apropiada.
• Observe que la implantación interna de Volumen utiliza

solicitudes para obtener Altura y Radio.
• Sin embargo, el aspecto más importante es la sencillez y

uniformidad que experimentan los usuarios de
CILINDRO.
• Sólo necesitan conocer la forma de enviar una solicitud y

las solicitudes disponibles.
TRES ENFOQUES DE CONSTRUCCIÓN DE BDOO.

• Las BDOO se pueden construir mediante alguno de los
tres enfoques siguientes:
• El Primero.- se puede utilizar el código actual altamente

complejo de los sistemas de administración de las BD, de
modo que una BDOO se implante más rápido sin tener
que iniciar de cero.

• El Primero…
• Las Técnicas OO se pueden utilizar como medios para el
diseño sencillo de sistemas complejos.
• Los sistemas se construyen a partir de componentes ya

probados con un formato definido para las solicitudes de
las operaciones del componente.

• El Segundo: Considera a la BDOO como una extensión
de la tecnología de las BD por Relación.
• De este modo, las herramientas, técnicas, y vasta
experiencia de la tecnología por relación se utilizan para
construir un nuevo SMBD.
• Se pueden añadir apuntadores a las tablas de relación para
ligarlas con objetos binarios de gran tamaño.
• La BD también debe proporcionar a las aplicaciones
clientes, un acceso aleatorio y por partes a grandes
objetos, con el fin de que sólo sea necesario recuperar a
través de la red la parte solicitada de los datos.

• El Tercero: reflexiona sobre la arquitectura de los SBD y
produce una nueva arquitectura optimizada, que cumple
las necesidades de la tecnología OO.
• Las compañías como Versant, Objectivity, Itasca, etc.,

utilizan este enfoque y afirman que la tecnología de
relación es un subconjunto de una capacidad más general.
• Además mencionan que las BDOO son aproximadamente

dos veces más rápidas que las bases de datos por relación,
para almacenar y recuperar la información compleja.

• El Tercero…
• Por lo tanto, son esenciales en aplicaciones como CAD y
permitirían que un depósito CASE fuera una facilidad de
tiempo real en vez de una facilidad por lotes.
• La Arquitectura de Versant está orientada al soporte
Cliente/Servidor con acercamiento a la computación
distribuida.
• Cualquier petición del Cliente, el Servidor la procesa. Los
servidores pueden cooperar en una BD distribuida de
Versant.
• Las BD pueden estar levantadas como un sistema m-
Cliente/n-Servidor.
IMPACTO DE LA ORIENTACIÓN A OBJETOS EN LA

INGENIERÍA DEL SOFTWARE.
• En las BDOO, la organización "Grupo de Administración
de Datos Objeto (ODMG)" representa el 100% de las
BDOO industriales.
• Y ha establecido un estándar de BD equivalente a SQL:
• ODL.- Lenguaje de Definición de Datos Objetos, y
• OQL.- Lenguaje de Consulta a Objetos.
• Respecto a las relacionales, todas (Oracle, Informix, etc.)

están añadiendo en mayor o menor grado algunos
aspectos de la OO.

• ANSI (Instituto Nacional Americano de Estándar), por su
parte, está definiendo un SQL-3 que incorpora muchos
aspectos de la OO.
• El futuro del SQL-3 es sin embargo incierto, ya que

ODMG ha ofrecido a ANSI su estándar para que sirva de
base para un nuevo SQL.
• Con lo que sólo habría un único estándar de BD.


• El grupo ODMG (Grupo Manejador de Datos Objeto)
nació de un grupo más grande, llamado "Grupo
Manejador de Objetos (OMG)“.
• Este grupo está definiendo un estándar universal por

objetos.
• Este estándar permitirá que un objeto sea programado en
cualquier lenguaje y sistema operativo.
• Facilitando enormemente el desarrollo de sistemas

abiertos cliente-servidor.
VENTAJAS EN BDOO.
• Está su flexibilidad, y soporte para el manejo de tipos de
datos complejos.
• Por ejemplo, en una BD convencional:
• Si una empresa adquiere varios clientes por referencia de
clientes- servicio.
• Pero la BD existente, que mantiene la información de clientes y
sus compras, no tiene un campo para registrar quién proporcionó
la referencia.
• O de qué manera fue dicho contacto.
• O si debe compensarse con una comisión, sería necesario
reestructurar la BD para añadir este tipo de modificaciones o de
datos.
VENTAJAS EN BDOO.
• Por el contrario, en una BDOO, el usuario puede añadir
una "subclase" de la clase de clientes para manejar las
modificaciones que representan los clientes por
referencia.
• La subclase heredará todos los atributos, características de

la definición original, además se especializará en
especificar los nuevos campos que se requieren así como
los métodos para manipular solamente esos campos.
• Naturalmente se generan los espacios para almacenar la

información adicional de los nuevos campos.
VENTAJAS EN BDOO.
• Esto presenta la ventaja adicional que una BDOO puede
ajustarse a usar siempre el espacio de los campos que son
necesarios, eliminando espacio desperdiciado en registros
con campos que nunca usan.
• La segunda ventaja de una BDOO, es que manipula datos

complejos en forma rápida y ágilmente.
• La estructura de la base de datos está dada por referencias

(o apuntadores lógicos) entre objetos, los famosos IDOs.
POSIBLES DESVENTAJAS.
• Al considerar la adopción de la tecnología orientada a
objetos, la inmadurez del mercado de BDOO constituye
una posible fuente de problemas.
• Por lo que debe analizarse con detalle la presencia en el

mercado del proveedor para adoptar su producto en una
línea de producción sustantiva.
• El segundo problema es la falta de estándares en la

industria OO.
• Sin embargo, el "Grupo Manejador de Objetos" (OMG),
es una organización Internacional de proveedores de
sistemas de información y usuarios dedicada a promover
estándares para el desarrollo de aplicaciones y sistemas
OO en ambientes de cómputo en red.
• La implantación de una nueva tecnología requiere que los

usuarios iniciales acepten cierto riesgo.
• Aquellos que esperan resultados a corto plazo y con un

costo reducido quedarán desilusionados.
• Sin embargo, para aquellos usuarios que planean:
• A un futuro intermedio con una visión tecnológica avanzada.

• El uso de tecnología avanzada o de punta.
• Y el uso de Tecnología OO.
• Paulatinamente compensarán todos los riesgos.

RENDIMIENTO.
• Las BDOO permiten que los objetos hagan referencia

directamente a otros mediante apuntadores suaves.
• Esto hace que las BDOO pasen más rápido del objeto A al
objeto B que las BDR.
• Las cuales deben utilizar comandos JOIN para lograr ésto.
• Incluso el JOIN optimizado es más lento que un recorrido

de los objetos.
RENDIMIENTO.
• Así, incluso sin alguna afinación especial, una BDOO es
en general más rápida en esta mecánica de caza-
apuntadores.
• Las BDOO hacen que el agrupamiento sea más eficiente.
• La mayoría de los SBD permiten que el operador coloque

cerca las estructuras relacionadas entre sí, en el espacio de
almacenamiento en disco.
• Esto reduce en forma radical el tiempo de recuperación de

los datos relacionados, puesto que todos los datos se leen
con una lectura de disco, en vez de varias.
RENDIMIENTO.
• Sin embargo, en una BDR, los objetos de la implantación
se traducen en representaciones tabulares que
generalmente se dispersan en varias tablas.
• Así, en una BDR, estos renglones relacionados deben

quedar agrupados, de modo que todo el objeto se pueda
recuperar mediante una única lectura del disco.
• Esto es automático en una BDOO.
• Además, el agrupamiento de los datos relacionados, como

todas las subpartes de un ensamble, puede afectar
radicalmente el rendimiento general de una aplicación.
RENDIMIENTO.
• Esto es relativamente directo en una BDOO, puesto que
representa el primer nivel de agrupamiento.
• Por el contrario, el agrupamiento físico es imposible en

una BDR, puesto que esto requiere un segundo nivel de
agrupamiento:
• Un nivel para agrupar las hileras que representan a los objetos

individuales
• Y un segundo para los grupos de hileras que representan a los

objetos relacionados.
RENDIMIENTO.
• Un SMBDOO debe satisfacer dos criterios:
• Ser un Sistema OO.
• Y ser un Sistema de Administración de BD.
• El primer criterio se traduce en ocho características

generales: Abstracción, encapsulación, modularidad,
jerarquía, control de tipos, concurrencia, persistencia y
genericidad.
• El segundo criterio se traduce en cinco características
principales: Persistencia, concurrencia, recuperación
ante fallos del sistema, gestión del almacenamiento
secundario y facilidad de consultas.
Características de SGBDOO .
Segundo Criterio. Con Primer Criterio. Con 8

5 características. características.
RENDIMIENTO.
• Como se puede observar la Persistencia, al igual que la
Concurrencia, son características del SMBDOO
heredadas tanto del SMBD como del Modelo de Objetos.
• La Persistencia en el caso del SMBD hace referencia a la

conservación de los datos después de la finalización del
proceso que los creó.
• En el caso del Modelo de Objetos, se refiere no sólo a la

conservación del estado de un objeto, si no también a la
conservación de la clase, que debe trascender a cualquier
programa individual.
RENDIMIENTO.
• De forma que todos los programas interpreten de la
misma manera el estado almacenado.
• La Concurrencia heredada del SMBD se refiere a la

capacidad del sistema para gestionar a múltiples usuarios
interactuando concurrentemente sobre el sistema.
• Mientras que la concurrencia heredada del Modelo de

Objetos, hace referencia a la capacidad de distinguir a un
objeto activo de otro que no lo está.
RENDIMIENTO.
• Persistencia.- Es la capacidad que tiene el programador
para que sus datos se conserven al finalizar la ejecución
de un proceso, de forma que se puedan reutilizar en otros
procesos.
• Concurrencia.- Se relaciona con la existencia de muchos

usuarios interactuando concurrentemente en el sistema.
• Éste debe controlar la interacción entre las transacciones

concurrentes, para evitar que se destruya la consistencia
de la BD.
RENDIMIENTO.
• Recuperación.- Proporcionar como mínimo el mismo
nivel de recuperación que los SBD actuales.
• De forma que, tanto en caso de fallo de hardware como de
software, el sistema pueda retroceder hasta un estado
coherente de los datos.
• Gestión del almacenamiento secundario.- Es soportada

por un conjunto de mecanismos que no son visibles al
usuario.
• Tales como gestión de índices, agrupación de datos,
selección del camino de acceso, optimización de
consultas, etc.
RENDIMIENTO.
• Gestión del almacenamiento secundario…
• Estos mecanismos evitan que los programadores tengan que escribir
programas para mantener índices, asignar el almacenamiento en
disco, o trasladar los datos entre el disco y la memoria principal.
• Creándose de esta forma una independencia entre los Niveles Lógicos

y Físicos del sistema.
• Facilidad de Consultas.-
• Permitir al usuario hacer cuestiones sencillas a la BD. Este tipo de
consultas tienen como misión proporcionar la información solicitada
por el usuario de una forma correcta y rápida.
INTEGRIDAD.
• Los sistemas de objetos no soportan generalmente
restricciones de integridad declarativas.
• En vez de ello, requieren que tales restricciones se hagan

cumplir por medio de código procedural (por métodos o
programas de aplicación).
• Niveles:
 Ningún soporte del sistema.
 Validación de referencias.
 Mantenimiento del sistema
 “Semántica personalizada”
CONTROVERSIA.
• Las BD de Objetos surgieron por la necesidad que tenían
los programadores de aplicaciones OO, de conservar sus
objetos en una memoria persistente.
• Esa memoria persistente podría considerarse una BD,

pero el punto importante es que en realidad fue
especificada por la aplicación.
• No era una BD compartida, de propósito general que

pretendiera ser adecuada para aplicaciones que no
hubieran sido previstas al momento de definir la BD.
CONTROVERSIA.
• Muchas características que son esenciales en los SBD,
sencillamente no fueron requerimiento en el mundo de los
objetos, al menos no originalmente.
• Se podría decir que un SBDOO no es un SMBD, por:

 Un SMBDR ya viene listo para ser usado. Tan pronto como el
sistema está instalado, los usuarios pueden comenzar a construir
y manipular las BDs.
 Un SMBDOO, por el contrario, puede ser visto como un Kit de
Construcción de SMBD. Cuando es instalado por primero vez,
NO está disponible para su uso inmediato. Primero debe ser
adaptado por técnicos capaces y experimentados.
CONTROVERSIA.
 Estos técnicos son quienes también definen las clases y métodos

necesarios para la BD. Y sólo cuando esta actividad de
adaptación haya terminado, el sistema estará disponible para que
los programadores de aplicaciones y los usuarios finales lo
utilicen.
 Se puede observar, que el SMBD “adaptado” resultante será
específico de una aplicación en particular.
 Podría por ejemplo, ser adaptado para aplicaciones CAD/CAM,
pero esencialmente inútil para otro tipo de aplicaciones (médicas,
documentos, etc).
 En otras palabras, todavía no sería un SMBD de propósito
general, como lo son los SMBDRs.
CONTROVERSIA.
• En esencia el modelo de objetos dice que podemos
almacenar cualquier cosa que queramos, cualquier
estructura de datos que podamos definir.
• El modelo relaciona dice lo mismo, pero además insiste

en que cualquier cosa que almacenemos debe ser
presentada ante el usuario en forma relacional pura.
• El modelo relacional no dice nada acerca de lo que puede

ser almacenado físicamente.
CONTROVERSIA.
• Por lo tanto no impone límites sobre cuáles estructuras de
datos son permitidas en el nivel físico.
• El único requerimiento es que cualquier estructura que de

hecho esté guardada físicamente, debe ser transformada a
relaciones en el nivel lógico y por lo tanto, debe ser oculta
ante el usuario.
• Los sistemas relacionales hacen una distinción clara entre

lo lógico y lo físico (el modelo de datos contra la
implementación).
CONTROVERSIA.
• Mientras que los sistemas basados en objetos no lo hacen.
SMBD DE
OBJETOS/RELACIONALES
SMBD O/R.
• Recientemente varios fabricantes han lanzado productos
SMBD “de Objetos/Relacionales”.
• También conocidos en el mercado, como Servidores

Universales.
• Ejemplos de éstos:
 Universal Database de DB2.

 Universal Data Option para Informix Dynamic Server.
 Oracle 8i Universal Server, Database Server o Enterprise Server.
SMBD O/R.
• La idea general es que los productos deben soportar
posibilidades de objetos y relacionales.
• Los productos en cuestión son intentos de un

“acercamiento” entre las dos tecnologías.
• En los SBDR, se complica el manejar estructuras

complejas, pero el soporte ya está ahí en forma de
Dominios.
• No se necesita hacer nada, para lograr la funcionalidad de

objetos en los sistemas relacionales.
SMBD O/R.
• Es decir, sólo se necesita implementarlo, completa y
adecuadamente.
• Por lo tanto, se cree que un sistema relacional que soporte

adecuadamente los dominios, sería capaz de manejar
todos estos tipos de datos “problemáticos”, que según se
dice, sólo pueden manejar los sistemas de objetos.
• También se cree que un sistema de “objetos/relacional”

verdadero, sería un sistema relacional verdadero.
SMBD O/R.
• Los fabricantes de SMBD deberían ser motivados para
que hicieran lo que, de hecho, están tratando de hacer.
• Extender sus sistemas para que incluyan el soporte

apropiado de tipos o dominios.
• Una implicación importante del soporte apropiado para

los tipos de datos, es que se permite que los fabricantes de
otras compañías construyan y vendan paquetes de “tipos
de datos” separados, que pueden ser incorporados al
SMBD.
SMBD O/R.
• Estos paquetes incluyen soporte para el manejo de Texto
Sofisticado, el procesamiento de Series de Tiempo
Financieras, el Análisis de Datos Geoespaciales
(cartográficos), etc.
• A dichos paquetes se les conoce de diversas formas:

 Navajas de Datos (Informix).
 Cartuchos de Datos (Oracle)
 Extensores Relacionales (IBM)
SMBD O/R.
• Sin embargo, la incorporación de un nuevo paquete de
tipos al sistema es una labor no trivial.
• Y la capacidad de hacerlo tiene implicaciones importantes

para el diseño y la estructura del propio SMBD.
• Por ejemplo, considere lo que pasaría si alguna consulta

incluyera referencia hacia datos de algún tipo definido por
el usuario, o invocaciones a algún operador definido por
el usuario.
SMBD O/R.
• Consideraciones para el sistema:
 El compilador del lenguaje de consultas debe ser capaz de
analizar sintácticamente y verificar el tipo que se solicita. Por lo
que tiene que saber acerca de esos tipos y operadores definidos.
 El optimizador tiene que ser capaz de decidir un plan de consulta

adecuado para esa solicitud y por lo tanto, estar consciente de las
propiedades de los tipos y operadores definidos.
 El componente que administra el almacenamiento físico tiene que

soportar las estructuras de almacenamiento nuevas.
SMBD O/R.
• El efecto de lo anterior es que el sistema necesita ser
extensible, y en varios niveles:
• Análisis sintáctico y verificación de tipos.

 En un sistema en el cual los usuarios pueden definir sus propios
tipos y operadores, no se puede manejar de manera integrada el
análisis y verificación de tipos por el compilador del lenguaje de
consultas.
 Se debe rediseñar el catálogo del sistema (o al menos extendido).
 El compilador mismo necesita ser reescrito para acceder al

catálogo a fin de obtener la información necesaria.
SMBD O/R.
• Optimización.
 Transformación de expresiones (reescritua de consultas). Debe
ser dinámico, y no preestablecido.
 Selectividad. Porcentaje de tuplas que la hacen verdadera. Esta

selectividad debe ser “integrado” en el optimizador.
 Fórmulas de Costo. El optimizador necesita saber cuánto cuesta

ejecutar un operador definido por el usuario.
 Estructuras de Almacenamiento y Métodos de Acceso. El

optimizador debe conocer esta información.
SMBD O/R.
• En resumen, Stonebraker está argumentado que los
“sistemas de Objetos/Relacionales están en el futuro de
todos”.
ESTÁNDARES
PRIMER INTENTO DE ESTANDARIZACIÓN: ODMG-

93.
• La mayor limitación de las BDOO es la carencia de un
estándar.
• ODMG-93 (Object-Oriented Database Management

Group) es un punto de partida muy importante para ello.
• Adopta una arquitectura que consta de un sistema de

gestión que soporta un lenguaje de BDOO, con una
sintaxis similar a un lenguaje de programación, también
OO como puede ser C++ o Smalltalk.

93.
• El Lenguaje de BD se especifica mediante:
• Un Lenguaje de Definición de Datos (ODL).

• Un Lenguaje de Manipulación de Datos (OML).
• Y un Lenguaje de Consulta (OQL).
• Siendo todos ellos portables a otros sistemas, con el fin de

conseguir la portabilidad de la aplicación completa.

93.
• En definitiva, ODMG-93 intenta definir un SMBDOO
que integre las capacidades de las BD con las capacidades
de los lenguajes de programación.
• De forma que los objetos de la BD 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.

93.
• El SMBDOO extiende el lenguaje con persistencia,
concurrencia, recuperación de datos, consultas
asociativas, etc.
Lenguaje ODL
• El Lenguaje de Definición de Datos (ODL) en un

SMBDOO es empleado para facilitar la portabilidad de
los esquemas de las BD.
LENGUAJE ODL
• Este ODL no es un lenguaje de programación completo,
define las propiedades y los prototipos de las operaciones
de los tipos, pero no los métodos que implementan esas
operaciones.
• El ODL intenta definir tipos que puedan implementarse en

diversos lenguajes de programación.
• No está por tanto ligado a la sintaxis concreta de un

lenguaje de programación particular.
LENGUAJE ODL
• De esta forma un esquema especificado en ODL, puede

ser soportado por cualquier SMBDOO que sea compatible
con ODMG-93.
• La sintaxis de ODL es una extensión de la IDL (Interface

Definition Language) desarrollado por OMG como parte
de CORBA (Common Object Request Broker
Architecture).
LENGUAJE OML.
• El Lenguaje de Manipulación es empleado para la

elaboración de programas que permitan crear, modificar y
borrar datos que constituyen la BD.
• ODMG-93 sugiere que este lenguaje sea la extensión de

un lenguaje de programación, de forma que se pueden
realizar entre otras las siguientes operaciones sobre la
base de datos: Creación, Borrado, Modificación e
Identificación de un Objeto.
LENGUAJE OQL.
• El Lenguaje de Consulta propuesto por ODMG-93,

presenta las siguientes características:
• No es computacionalmente completo. Sin embargo, las consultas

pueden invocar métodos, e inversamente los métodos escritos en
cualquier lenguaje de programación pueden incluir consultas.
• Tiene una sintaxis abstracta.
• Su semántica formal puede definirse fácilmente.
• Proporciona un acceso declarativo a los objetos.

LENGUAJE OQL.
• Se basa en el modelo de objetos de ODMG-93.
• Tiene una sintaxis concreta al estilo SQL, pero puede cambiarse

con facilidad.
• Puede optimizarse fácilmente.
• No proporciona operadores explícitos para la modificación, se

basa en las operaciones definidas sobre los objetos para ese fin.
• Proporciona primitivas de alto nivel para tratar con conjuntos de

objetos, pero no restringe su utilización con otros constructores
de colecciones.
LENGUAJE OQL.
• Existen dos posibilidades para asociar un sublenguaje de

consulta a un lenguaje de programación: fuerte y
débilmente.
• El primer caso, Lenguaje de Programación Fuerte,

consiste en una extensión de la gramática del lenguaje
asociado.
• En el segundo caso, Lenguaje de Programación Débil, las

funciones query tienen unos argumentos String que
contienen las preguntas.
LENGUAJE OQL.
Ejemplo de una consulta con OQL, presentando el aspecto de SQL:
d_Set< d_Ref<Cuenta> > resultado;

d_OQL_Query q1(“select a
from Cliente c, c.cuentas a
where c.nombre = ‘Juan’
and c.obtener_saldo() > 100”);
d_oql_execute(q1, resultado);
LENGUAJE OO.
• Para poder utilizar a los Lenguajes OO en un sistema de

BD, existen dos alternativas:
• Se pueden utilizar como herramientas de diseño y codificación.

Por ej. Una interfaz en una BDR.
• Extender el lenguaje de tratamiento de datos como SQL,

añadiendo tipos complejos y la POO. Los sistemas que
proporcionan extensiones de este tipo a sistemas relacionales, se
denominan Relaciones Orientadas a Objetos (ROO).
• Otra opción es tomar un lenguaje de POO y extenderlo para que

trabaje con las BD. Estos lenguajes se denomiann Lenguajes de
Programación Persistente.
CONCLUSIONES.
• En conclusión sabemos que las BDOO representan el

siguiente paso en la evolución de las BD, para soportar el
Análisis, Diseño y Programación OO.
• Las BDOO permiten el desarrollo y mantenimiento de

aplicaciones complejas con un costo significativamente
menor.
• Permiten que el mismo modelo conceptual se aplique al

análisis, diseño, programación, definición y acceso a la
BD.
CONCLUSIONES.
• Esto reduce el problema del operador de traducción entre

los diferentes modelos a través de todo el ciclo de vida del
sistema.
• El modelo conceptual debe ser la base de las herramientas

CASE OO totalmente integradas, las cuales ayudan a
generar la estructura de datos y los métodos.
• Las BDOO ofrecen un mucho mejor rendimiento de la

máquina que las BDR, para aplicaciones o clases con
estructuras complejas de datos.
CONCLUSIONES.
• Sin embargo, las BDOO coexistirán con las BDR durante

los próximos años.
• Puesto que a menudo se utilizará un modelo por relación

como una forma de estructura de datos, dentro de una
BDOO.
• Podemos decir que en conclusión, con el caso de Oracle,

que ha aumentado la demanda de una representación de
objetos complejos en las actuales aplicaciones
convencionales.
Principles Of Distributed Database Systems 2ª. Ed.

M. Tamer Ozsu y Patrick Valduriez
Prentice Hall
Procesamiento de Bases de Datos 8a. Ed.
David M. Kroenke
Pearson.
Introducción a los Sistemas de Bases de Datos 7a. Ed.
C. J. Date
Prentice Hall.
http://www.cs.cinvestav.mx/BDChapa/Beto/Blanco.htm
http://www.itlp.edu.mx/publica/tutoriales/basedat1/tema7.htm
http://www.itlp.edu.mx/publica/revistas/revista_isc/anteriores/mzo99/b
doo.html
http://www.elrinconcito.com/articulos/BaseDatos/BasesDatos.htm
http://www.inf.udec.cl/revista/ediciones/edicion2/crossel.PDF

Semana 01

Cargado por

Copyright:

Formatos disponibles

Semana 01

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Semana 01

Cargado por

Copyright:

Formatos disponibles

Ing.

de Sistemas UPP BDOO

• Hace algunos años, la creación de nuevas aplicaciones

• Su alto nivel de características lingüísticas y sus

• La integridad de los datos está controlada por el SBD.

• Es decir, el SBD debe ser responsable de cada programa

• Existe un conjunto de rutinas que facilitan el formateo de

• En la década pasada se generó mucho interés sobre los

• Estos sistemas tienen su origen en los lenguajes de POO.

• Donde los usuario no tienen que luchar contra las

• Sino que en su lugar deben tener la posibilidad de manejar

• En otras palabras, la idea fundamental es elevar el nivel

• Elevar el nivel de abstracción es incuestionablemente un

• La pregunta sería: Si el paradigma de la POO también

• La idea de manejar una BD que está compuesta de

• Aunque las disciplinas de los lenguajes de Programación

• Un programa de aplicación está hecho, por definición, para

• Por el contrario, una BD está hecha para resolver una variedad de

• Mucha gente cree que los Sistemas de Objetos

• Creen que las técnicas de objetos son el enfoque a escoger

• Actualmente, los sistemas de software han puesto un

• La disponibilidad de alta ejecución en las estaciones

• Algunos ejemplos son:

 Sistemas de Información de Oficinas (OIS).

• Todas éstas son áreas en las que los productos SQL

• Sin embargo, a lo largo de los años han sido

• Pero el problema continúa, sobre todo en nuevas

• Donde el nivel de complejidad de estos programas y

• Actualmente los programas de aplicación, en

• Aquí el estado del arte es difícil, como en la misma

• El desarrollo de las Bases de Datos Orientadas a

• Además combina las mejores cualidades de los

• Las BDOO representan el siguiente paso (?) en la

• Estás permiten el desarrollo y mantenimiento de

• Reduciendo el problema entre los diferentes modelos

• Como cualquier BD programable, una BDOO da un

• Permiten que el mismo modelo conceptual se aplique

• Esto reduce el problema del operador de traducción

• El modelo conceptual debe ser la base de las

• Además las BDOO ofrecen un mejor rendimiento en

• Sin embargo, las BDOO coexistirán con las BD

• El propósito de los Sistemas de Bases de Datos (SBD) es

• Las primeras BD surgieron del desarrollo de los sistemas

• Estos sistemas primero evolucionaron en BD de Red o en

• Las aplicaciones de BD tradicionales consisten en tareas

• Tales aplicaciones presentan conceptualmente tipos de

• Los elementos de datos básicos son registros bastante

• Es decir, estos campos no contienen estructuras

• Las BD Relacionales (BDR) almacenan los datos en

• De tal manera, la BDR no son adecuadas para almacenar

• Además, los objetos incluyen instrucciones ejecutables, o

• Los SMBDOO, se desarrollaron a principios de la década

• Sin embargo estos productos no se han comercializado

• Las organizaciones no realizan esta conversión porque es

• En respuesta a esto, los proveedores de los DBMS

• Así como también, el almacenamiento tradicional de datos

• A tales productos se les llama SMBD de Objeto/

• En particular Oracle, ha desarrollado diversos recursos

• Existen dos estándares importantes de objetos: El SQL3 y