INSTITUTO TECNOLOGICO SUPERIOR

DE ALVARADO – Campus Medellín

INGENIERÍA EN
SISTEMAS COMPUTACIONALES

Materia:
Fundamentos de Bases de Datos

Semestre - Grupo - Sistema:

4° Semestre – Escolarizado.

Producto Académico:
Investigacion Documental:
Bases de Datos Orientados a Objetos

Presenta:
Reyes Velazquez Miguel Angel

Docente:
I.S.C: Gustavo Zamorano Granda
 Índice
Portada ……………………………………………………………………………………………......Pág. 1

Índice………………………………………………………………………………………………………Pág. 2

Introducción……………………………………………………………………………………..……Pág. 3

Historia……………………………………………………………………………………………….…Pág. 4

Bases de datos oreintadas a objetos………………………………………………………Pág. 5

Estructura de una base de datos orientada a objetos ……………………….Pág. 7

Características de BD OO………………………………………………………………………Pág.12

Conclusión ……………………………………………………………………………………………Pág. 13
 Introducción
En una base de datos orientada a objetos, la información se representa mediante
objetos como los presentes en la programación orientada a objetos. Cuando se
integra las características de una base de datos con las de un lenguaje de
programación orientado a objetos, el resultado es un sistema gestor de base de
datos orientada a objetos (ODBMS, object database management system). Un
ODBMS hace que los objetos de la base de datos aparezcan como objetos de un
lenguaje de programación en uno o más lenguajes de programación a los que dé
soporte. Un ODBMS extiende los lenguajes con datos persistentes de forma
transparente, control de concurrencia, recuperación de datos, consultas
asociativas y otras capacidades.

Las bases de datos orientadas a objetos se diseñan para trabajar bien en

conjunción con lenguajes de programación orientados a objetos como Java, C#,
Visual Basic.NET y C++. Los ODBMS usan exactamente el mismo modelo que
estos lenguajes de programación.

Los ODBMS son una buena elección para aquellos sistemas que necesitan un
buen rendimiento en la manipulación de tipos de dato complejos.

Los ODBMS proporcionan los costes de desarrollo más bajos y el mejor

rendimiento cuando se usan objetos gracias a que almacenan objetos en disco y
tienen una integración transparente con el programa escrito en un lenguaje de
programación orientado a objetos, al almacenar exactamente el modelo de objeto
usado a nivel aplicativo, lo que reduce los costes de desarrollo y mantenimiento.
 Historia
Los orígenes del término orientados a objetos (abreviado OO) se remontan a los
lenguajes de programación orientadas a objetos. Los lenguajes de programación
OO tienen sus raíces en el lenguaje SIMULA 67, propuesto a finales de la década
de 1960. En Simula, el concepto de clase agrupa la estructura de datos interna de
un objeto en una declaración de clase, es decir, introduce en el lenguaje ALGOL
los conceptos de objeto y de clase. Como Algol, Simula es un lenguaje
fuertemente tipado para entornos compilados. Sin embargo, el primer lenguaje que
popularizó la aproximación a objetos fue Smalltalk (1976); este puede
considerarse una síntesis de años del lenguaje Lisp, que ofrece una gran
flexibilidad gracias a la interpretación, y de Simula, añadiendo el concepto de
metaclase. Smalltalk ha podido responder a las necesidades de flexibilidad
presentadas por el desarrollo de entornos de programación gráficos, favoreciendo
la rápida creación de prototipos de interfaces de usuarios amigables. Fue utilizado
con éxito en la primera estación gráfica de Xerox.

Con la llegada de las estaciones de trabajo en los años 80, han crecido
numerosos lenguajes orientados a objetos inspirados en Simula o Smalltalk. Entre
los lenguajes compilados, los más célebres son C++, Objective C y Eiffel, debido a
la compatibilidad del lenguaje o del código producido con el lenguaje de
programación C. La mayor parte de los lenguajes interpretados son extensiones
del Lisp; por ejemplo, Loops y CLOS. Es interesante notar que la mayor parte de
los lenguajes populares existentes se encuentran en curso de ampliación para
convertirse en orientados a objetos, incluyendo al COBOL y Ada (más
exactamente Ada 9X, que aporta la herencia).

En años recientes, han aparecido muchos prototipos experimentales y sistemas de

bases de datos comerciales orientados a objetos. Entre los primeros se
encuentran los sistemas ORION, OpenOODB, IRIS, ODE y el proyecto
ENCORE/ObServer. Y entre los sistemas disponibles en el mercado están:
GEMSTONE/OPAL de ServicLogic, ONTOS de Ontologic, Objectivity de
Objectivity Inc., Versant de Versant Technologies, ObjecStore de Object Design y
O2 de O2 Technology. Esta es solo una lista parcial de los prototipos
experimentales y de los sistemas de bases de datos comerciales orientados a
objetos. Desafortunadamente, es aún demasiado pronto para saber cuáles
sistemas se instalarán como líderes en este campo.

Las bases de datos orientadas a objetos han adoptado muchos de los objetos
creados para los lenguajes de programación orientados a objetos.
 Bases de datos orientados a objetos
Las Bases de datos orientados a objetos se propusieron con la idea de satisfacer
las necesidades de las aplicaciones más complejas. El enfoque orientado a
objetos ofrece la flexibilidad para cumplir con algunos de estos requerimientos sin
estar limitado por los tipos de datos y los lenguajes de consulta disponibles en los
sistemas de bases de datos tradicionales.
Como cualquier Bases de Datos programable, una Base de Datos Orientada a
Objetos (BDOO) proporciona un ambiente para el desarrollo de aplicaciones y un
depósito persistente listo para su explotación. Una BDOO almacena y manipula
información que puede ser digitalizada (presentada) como objetos, además
proporciona un acceso ágil y permite una gran capacidad de manipulación.
Los principales conceptos que se utilizan en las Bases de Datos Orientada a 
Objetos (BDOO) son las siguientes:

· Identidad de objetos
· Constructores de tipos
· Encapsulamiento
· Compatibilidad con los lenguajes de programación
· Jerarquías de tipos y herencia
· Manejo de objetos complejos
· Polimorfismo y sobrecarga de operadores  y
· Creación de versiones.

Bases De Datos Orientadas A Objetos

Este modelo, bastante reciente, y propio de los modelos informáticos orientados a
objetos, trata de almacenar en la base de datos los objetos completos (estado y
comportamiento).

Una base de datos orientada a objetos es una base de datos que incorpora todos
los conceptos importantes del paradigma de objetos:

· Encapsulación – Propiedad que permite ocultar la información al resto de

los objetos, impidiendo así accesos incorrectos o conflictos.
· Herencia – Propiedad a través de la cual los objetos heredan
comportamiento dentro de una jerarquía de clases.
 · Polimorfismo – Propiedad de una operación mediante la cual puede ser
aplicada a distintos tipos de objetos.

En bases de datos orientadas a objetos, los usuarios pueden definir operaciones

sobre los datos como parte de la definición de la base de datos. Una operación
(llamada función) se especifica en dos partes. La interfaz (o signatura) de una
operación incluye el nombre de la operación y los tipos de datos de sus
argumentos (o parámetros). La implementación (o método) de la operación se
especifica separadamente y puede modificarse sin afectar la interfaz. Los
programas de aplicación de los usuarios pueden operar sobre los datos invocando
a dichas operaciones a través de sus nombres y argumentos, sea cual sea la
forma en la que se han implementado. Esto podría denominarse independencia
entre programas y operaciones.

SQL: 2003, es el estándar de SQL92 ampliado, soporta los conceptos orientados a

objetos y mantiene la compatibilidad con SQL92.
 Estructura de una BD OO
El paradigma orientado a objetos se basa en el encapsulamiento de datos y  del
código relacionado con cada objeto en una sola unidad. Conceptualmente, todas
las interacciones entre cada objeto y el resto del sistema se realizan mediante
mensajes. Por lo tanto, la interfaz entre cada objeto y el resto del sistema se
define mediante un conjunto de mensajes permitidos.

 En general,  cada objeto está asociado con:

Un conjunto de variables que contiene los  datos  del  objeto; las variables
corresponden con los atributos del  modelo E-R.

Un conjunto de mensajes a los que responde;  cada  mensaje puede o no tener

parámetros o tener uno o varios.

Un conjunto de métodos, cada uno de los cuales es el código que implementa un  

mensaje;  el  método  devuelve  un  valor como respuesta al mensaje.

Mensaje en entorno OO no implica uso de mensajes físicos en redes informáticas.

Por el contrario,  hace referencia al intercambio de solicitudes entre los objetos,
independientemente de los detalles correctos de su implementación. Se utiliza a
veces la expresión invocar un método para detonar al hecho de enviar un mensaje
a un objeto y la ejecución del método correspondiente.

A.   IDENTIDAD DE  OBJETOS

Un sistema de BDOO provee una identidad única a cada objeto independiente

almacenado en la base de datos. Esta identidad única suele implementarse con un
identificador de objeto único, generado por el sistema, u OID. El valor de un OID
no es visible para el usuario externo, sino que el sistema lo utiliza a nivel interno
para identificar cada objeto de manera única y para crear y manejar las referencias
entre objetos.

La principal propiedad que debe tener un OID es la de ser inmutable; es decir, el

valor del OID para un objeto en particular nunca debe cambiar. Esto preserva la
identidad del objeto del mundo real que se está presentando. También es
preferible que cada OID se utilice sólo una vez; esto es aunque un objeto se
elimine de la Base de datos, su OID no se deberá asignar a otro objeto. Estas dos
propiedades implican que el OID no debe depender del valor de ningún atributo
del objeto, pues estos valores pueden cambiar. También suele considerarse
inapropiado basar el OID en la dirección física del objeto en el almacenamiento, ya
que una reorganización de los objetos de la base de datos podría cambiar los OID.
Sin embargo, algunos sistemas sí usan la dirección física como OID para
aumentar la eficiencia de la obtención de los objetos. Si la dirección física cambia,
puede colocarse un apuntador indirecto en la dirección anterior, dando la nueva
ubicación física del objeto. Un sistema de BDOO debe contar con algún
mecanismo para generar los OID con la propiedad de inmutabilidad.

Algunos modelos de datos OO requieren que todo se represente como un objeto,

ya sea un valor simple o un objeto complejo; así, todo valor básico, como un
entero, una cadena o un valor booleano, tiene un OID. Con ello dos valores
básicos pueden tener diferentes OID, lo cual es muy útil en algunos casos. Por
ejemplo, en algunas ocasiones se podría usar el valor entero 50 para representar
un peso en Kilogramos, y en otras para referirse a la edad de una persona. Así
podrían crearse dos objetos básicos con diferentes OID, y ambos tendrían el
mismo valor básico de 50. Aunque resulta útil como modelo teórico, esto no es
muy práctico porque puede obligar a generar demasiados OID. Por ello también, la
mayor parte de los sistemas de BDOO permiten representar tanto objetos como
valores. Todo objeto debe tener un OID inmutable, pero los valores no tienen OID
y se representan así mismo.

 Los objetos tienen identidades únicas, independientes de los valores de sus

atributos.
 La estructura orientad a objetos automáticamente impone las restricciones
relacionales, generalmente más aplicables: dominio, llave integridad de
entidad e integridad referencial.

B.  CONSTRUCTORES DE TIPOS

En las BDOO, los valores (o estados) de los objetos complejos se pueden
construir a partir de otros objetos mediante ciertos constructores de tipos. Una
forma de representar tales objetos es considerar a cada objeto como tripleta (i, c,
v), donde i es un identificador de objeto único (el OID), c es un constructor (esto
es, una indicación de cómo se construye el valor del objeto) y v es el valor (o
estado) del objeto. Puede haber varios constructores, según el modelo de datos y
el sistema OO.

Los tres constructores  básicos son:

 constructores de átomos.
 constructores de tuplas.
 constructores de conjuntos.
Otros constructores de uso más común son los de listas y de arreglos. También
existe un dominio D que contiene todos los valores atómicos básicos que están
disponibles directamente en el sistema. Por lo regular estos incluyen los enteros,
los números reales, las cadenas de caracteres, los tipos boléanos, las fechas y
cualesquiera otros tipos de datos que el sistema maneje directamente.

C. ENCAPSULAMIENTO:
Tanto la estructura de los objetos como las operaciones que se pueden aplicar a
ellos se incluyen en las definiciones de clases de los objetos.

D.  COMPATIBILIDAD CON  LENGUAJES DE

PROGRAMACION
Si se sigue el enfoque cuando se utilizan los diagramas de Entidad-Relación para
modelar los datos y luego se convierten de manera manual en un conjunto de
relaciones; por lo tanto los conceptos de la Programación Orientada a Objetos se
utilizan simplemente como herramientas de diseño y se codifican, utilizándose
para trabajar  con una base de datos.

Hay varios lenguajes posibles en los que se pueden integrar estos conceptos:

 Una opción es extender un lenguaje para el tratamiento de datos como el

SQL añadiendo tipos complejos y la programación orientada a objetos. Los
sistemas proporcionan extensiones orientadas a objetos a los sistemas
relacionales se denominan sistemas relacionales orientados a objetos.
 Otra opción es tomar un lenguaje de programación orientado a objetos ya
existente y extenderlo para que trabaje con las bases de datos. Estos
lenguajes se denominan lenguajes de programación persistentes. Estos
lenguajes permiten a los programadores trabajar directamente con los
datos, desde el lenguaje de programación; sin tener que pasar por un
lenguaje para el tratamiento de datos como SQL. Se denominan
persistentes porque los datos  siguen existiendo una vez que el programa
que los creó ha concluido.
 A la hora de decidir que opción utilizar se debe tener en cuenta que  los
Lenguajes Persistentes suelen ser potentes y resulta relativamente sencillo
cometer errores de programación que dañen las bases de datos. La
complejidad de los lenguajes hace la optimización automática de alto nivel,
como la reducción de E/S de disco, resulte difícil. En muchas aplicaciones,
la posibilidad de las consultas declarativas es de gran importancia, pero los
 lenguajes persistentes no permiten actualmente las consultas declarativas
sin que aparezcan problemas de algún tipo.

E.  JERARQUIA DE TIPOS Y HERENCIA

Los esquemas de BDOO suelen necesitar un gran número de clases. Sin
embargo, varias clases son parecidas entre sí.
Para permitir la representación directa de parecidos entre las clases, hay que
ubicarlas en una jerarquía de especializaciones. El concepto de jerarquía de
clases es parecido al de especialización del modelo E-R. Las especializaciones de
las clases son denominadas subclases; lo cual especifica atributos y métodos
adicionales para una clase existente. Los objetos creados por medio de unas
subclases heredan todos los atributos y  métodos de la clase padre. Algunas de
estas características heredadas pueden ellas mismas haber sido heredadas de
clases más altas en la jerarquía.

F. MANEJO DE OBJETOS COMPLEJOS

Los objetos se consideran complejos porque requieren un área de
almacenamiento sustancial y no forman parte de los tipos de datos estándar que
suelen ofrecer los SGBD. Puesto que el tamaño de los objetos es considerable, un
SGBD podría obtener una porción del objeto y proporcionarla al programa de
aplicación antes de obtener todo el objeto. El SGBD podría también usar técnicas
de almacenamiento intermedio y caché para obtener por anticipado porciones del
objeto, antes de que el programa de aplicación necesite tener acceso a ellas.

En un SGBOO, esto puede lograrse definiendo un nuevo tipo de datos abstracto

para los objetos no interpretados y suministrados los médos para seleccionar,
comprar y exhibir tales objetos.

Como un SGBOO permite a los usuarios crear nuevos tipos, y como un tipo
incluye tanto estructura como operaciones, podemos considerar que un SGBOO
tiene un sistema de tipos extensibles. Podemos crear bibliotecas  de nuevos tipos
definiendo su estructura y operaciones, incluso con tipos complejos.

Muchos SGBDOO pueden almacenar y obtener objeto no estructurado extenso en

forma de cadenas y caracteres o de bits, que se pueden pasar “tal cual” al
programa de aplicación para que las interprete.

 Es posible almacenar y manipular objetos complejos tanto estructurados

como no estructurados. 
G. POLIMORFISMO
El polimorfismo se refiere al uso de la misma firma de mensaje para dirigir
diferentes métodos en diferentes clases. Cuando el diseñador envía una señal a
un objeto, el método de la clase de objeto, posiblemente heredado, procesa la
señal.

Un método puede tener acceso directamente a atributos de un objeto destino por

no nombre, al incluir cualesquiera atributos heredados de clases padres, pero
debe tener acceso a atributos de otros objetos con señales secundarias.

En síntesis este concepto permite enlazar el mismo nombre o símbolo de operador

a dos o más implementaciones diferentes del operador, dependiendo del tipo de
objetos a los que éste se aplique.

H. CREACION DE VERSIONES
Muchas aplicaciones de bases de datos que usan sistemas OO requieren la
existencia de varias versiones del mismo objeto.

Por lo regular, se aplican actividades de mantenimiento a un sistema de software

conforme sus requerimientos evolucionan. Por lo regular,  el mantenimiento
implica modificar algunos de los módulos de diseño y de implementación. Si el 
sistema ya está en operación, y si es preciso modificar uno o más módulos, el
diseñador deberá crear una nueva versión de cada uno de ellos para efectuar
cambios.

Cabe señalar que puede haber más de dos versiones de un objeto.

En caso que se requieran dos versiones, además del módulo original. Se puede
actualizar concurrentemente las propias versiones del mismo módulo del software.
Esto se llama ingeniería concurrente. Sin embargo, siempre llega el momento en
que es preciso combinar (fusionar) estas dos versiones para que la versión hibrida
incluya los cambios realizados. Es necesario de que sus cambios sean
compatibles.

Un objeto complejo, como  un sistema de software, puede constar de muchos

módulos. Cuando se permite la creación de múltiples versiones, es posible que
cada una de esos módulos  tenga varias versiones distintas y un grafo de
versiones.

Como se deduce del análisis anterior, un SGBDOO debe ser capaz  de 
almacenar  y  controlar  múltiples  versiones  del mismo objeto.
 Características de BD OO
Se  intenta definir un sistema de BDOO y describe las principales características  
en tres grupos:

Mandatarias: son las que el Sistema debe satisfacer a orden de tener un sistema

de BDOO y estos son: Objetos complejos, Identidad de Objetos, Encapsulación,
Tipos o clases, Sobre paso con unión retardada, Extensibilidad, Completación
Computacional, Persistencia y Manejador de almacenamiento secundario,
Concurrencia, Recuperación y Facilidad de Query.

CARACTERISTICAS OBLIGATORIAS
Este es un punto que no debe faltar en BD.

Predominancia combinada con enlace retardado: se puede definir que sea

Excel, Autocad, etc. desde la programación.

Extensibilidad: Proporciona los tipos de datos como: Carácter, booleano, string,

etc.

Concurrencia: permite que varios usuarios tengan acceso a      una BD al mismo
tiempo.

Recuperación: Cuando se hace una transacción pero no se puede realizar y se

regresa al mismo estado.
Facilidad de “Consultas a Modo”. Esto es cuando se tienen diferentes estándares.
 Conclusión
La clave que posee la BDOO es el poder que confieren al diseñador para
especificar tanto la estructura de objetos complejos como las operaciones que se
pueden aplicar a esos objetos.

Está su flexibilidad, y soporte para el manejo de tipos de datos complejos.  Por

ejemplo: En una base de datos convencional, si una empresa adquiere varios
clientes por referencia de clientes servicio, pero la base de datos existente, que
mantiene la información de clientes y sus compras, no tiene un campo para
registrar quién proporcionó la referencia, de qué manera fue dicho contacto, o si
debe compensarse con una comisión, sería necesario reestructurar la base de
datos para añadir este tipo de modificaciones. 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 estos campos Naturalmente se
generan los espacios para almacenar la información adicional de los nuevos
campos. 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. 

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 la línea de producción sustantiva. Por eso en este artículo se propone
que se explore esta tecnología en un proyecto piloto.

El segundo problema es la falta de estándares en la industria orientadas a objetos.

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 orientados a
objetos en ambiente de cómputos de 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 que planean a un futuro intermedio
con una visión tecnológica avanzada, el uso de tecnología avanzada, el uso de
tecnología orientada a objetos, paulatinamente compensará todos los riesgos.