INSTITUTO TECNOLOGICO SUPERIOR DE CINTALAPA

MATERIA:

TOPICOS DE BASE DE DATOS

UNIDAD II

INVESTIGACION:

“SISTEMA DE BASE DE DATOS ORIENTADA A OBJETOS”

CATEDRATICO:

LUIS GERMAN MONTESINOS ALFARO

ALUMNO:

FRANCISCO DE JESUS GOMEZ CASTELLANOS

CARRERA:

INGENIERIA INFORMATICA

7° SEMESTRE GRUPO “E”

CINTALAPA DE FIGUEROA A 11/09/2018

 INTRODUCCION
En la presente investigación del tema Sistema de base de base de datos orientada
a objetos, hablaremos de temas importantes que crean gran relevancia dentro de
los sistemas el Modelo de datos orientados a objetos, la existencia de problemas
para representar cierta información y modelar ciertos aspectos del "mundo real",
puesto que los modelos clásicos permiten representar gran cantidad de datos,
pero las operaciones y representaciones que se pueden realizar sobre ellos son
bastante simples. Las características de SGBDOO, Debe soportar objetos
complejos. Debe ser posible construir objetos complejos aplicando constructores a
objetos básicos. Identidad del objeto. Todos los objetos deben tener un
identificador, el cual es independiente de los valores de sus atributos. Tipos de
SGBDOO, SGBD de red. Los SGBD relacionales se basan en el modelo de datos
de red. Los datos en el modelo de red se representan mediante colecciones de
registros y las relaciones entre los datos se representan mediante enlaces, que se
pueden ver como punteros. Los registros en la base de datos se organizan como
colecciones de grafos dirigidos. En la figura se presenta un ejemplo de base de
datos en red. SGBD jerárquicos, los SGBD relacionales se basan en el modelo de
datos jerárquico. El modelo jerárquico es similar al modelo de redes, en el sentido
en que los datos y las relaciones entre los datos se representan. Estándar ODMG,
Este Modelo estándar ODMG, especifica los elementos que se definirán, y en qué
manera se hará, para la consecución de persistencia en las Bases de datos
orientadas a objetos que soporten el estándar. Consta de un lenguaje de definición
de objetos, ODL, que especifica los elementos de este modelo. Un grupo de
representantes de la industria de las bases de datos formaron el ODMG (Object
Database Management Group) con el propósito de definir estándares para los
SGBD orientados a objetos. Identidad y Estructura de Objetos, Identidad la
identidad es la propiedad que permite diferenciar a un objeto y distinguirse de
otros. Generalmente esta propiedad es tal, que da nombre al objeto. Estructura, es
la disposición, distribución y orden de las partes del cuerpo de una cosa
determinada inanimada, que puede ser perceptible por algún sentido, y se puede
accionar sobre ella.
2.1 Modelo de datos orientados a objetos

La existencia de problemas para representar cierta información y modelar ciertos

aspectos del "mundo real", puesto que los modelos clásicos permiten representar
gran cantidad de datos, pero las operaciones y representaciones que se pueden
realizar sobre ellos son bastante simples.

El paso del modelo de objetos al modelo relacional genera dificultades que en el

caso no surgen ya que el modelo es el mismo. Por lo tanto, las bases de datos
orientadas a objetos surgen básicamente para tratar de paliar las deficiencias de
los modelos anteriores y para proporcionar eficiencia y sencillez a las aplicaciones.

Las debilidades y limitaciones de los Sistema Gestor de Bases de Datos

Orientadas a Objetos son:

 Pobre representación de las entidades del "mundo real".

 Sobrecarga y poca riqueza semántica.

 Soporte inadecuado para las restricciones de integridad y empresariales

 Estructura de datos homogénea

 Operaciones limitadas

 Dificultades para gestionar las consultas re cursivas

 Des adaptación de impedancias

Problemas asociados a la concurrencia, cambios en los esquemas y el

inadecuado acceso navegacional.

No ofrecen soporte para tipos definidos por el usuario (sólo dominios) Mientras
que las necesidades de las aplicaciones actuales con respecto a las bases de
datos son:

 Soporte para objetos complejos y datos multimedia

  Identificadores únicos

 Soporte a referencias e interrelaciones

 Manipulación navegacional y de conjunto de registros

 Jerarquías de objetos o tipos y herencia

 Integración de los datos con sus procedimientos asociados

 Modelos extensibles mediante tipos de datos definidos por el usuario

 Gestión de versiones

 Facilidades de evolución

 Transacciones de larga duración

 Interconexión e interoperabilidad

Debido a las limitaciones anteriormente expuestas, su uso es más ventajoso si se

presenta en alguno de los siguientes escenarios:

Un gran número de tipos de datos diferentes

Un gran número de relaciones entre los objetos

Objetos con comportamientos complejos

Se puede encontrar este tipo de complejidad acerca de tipos de datos, relaciones

entre objetos y comportamiento de los objetos principalmente en aplicaciones de
ingeniería, manufacturación, simulaciones, automatización de oficina y en
numerosos sistemas de información. No obstante, las BDOO no están restringidas
a estas áreas. Ya que al ofrecer la misma funcionalidad que sus precursoras
relacionales, el resto de campos de aplicación tiene la posibilidad de aprovechar
completamente la potencia que las BDOO ofrecen para modelar situaciones del
mundo real.
2.1.1 Características de SGBDOO

Las características de un SGBDOO son:

1.-Debe soportar objetos complejos. Debe ser posible construir objetos complejos
aplicando constructores a objetos básicos.

2.-Identidad del objeto. Todos los objetos deben tener un identificador, el cual es
independiente de los valores de sus atributos.

3.-Encapsulamiento. Los programadores solo tienen acceso a la interfaz de los

métodos, y los datos e implementación de estos métodos están en los objetos.

4.-Tipos o clases. El esquema de una base orientada a objetos contiene un

conjunto de clases o tipos.

5.-Tipos o clases deben ser capaces de heredar de sus súper-tipos o superclases

los atributos y los métodos.

6.-La sobrecarga debe ser soportada, los métodos deben poder aplicarse a
diferentes tipos.

7.-El DML debe ser completo. El DML en los sistemas gestores de bases de datos
orientados a objetos debe ser un lenguaje de programación de propósito general.

8.-El conjunto de tipos de datos debe ser extensible. No habrá distinción entre los
tipos definidos por el usuario y los tipos definidos por el sistema,

9.-Persistencia de datos. Los datos deben mantenerse después de que la

aplicación que los creó haya finalizado, el usuario no tiene que hacer copia
explícitamente.

10.-El SGBD debe ser capaz de manejar bases de datos grandes.

11.-El SGDB debe soportar la concurrencia. Debe disponer del mecanismo para el
control de la concurrencia.
12.-Recuperaci¢n. El sistema gestor debe de proveer mecanismos de
recuperación de la información en caso de fallo de sistema.

13.-El SGDB debe proveer de manera fácil de hacer consultas.

2.1.2 Tipos de SGBDOO 

SGBD de red. 

Los SGBD relacionales se basan en el modelo de datos de red. Los datos en el

modelo de red se representan mediante colecciones de registros y las relaciones
entre los datos se representan mediante enlaces, que se pueden ver como
punteros. Los registros en la base de datos se organizan como 

colecciones de grafos dirigidos. En la figura se presenta un ejemplo de base de

datos en red. 

SGBD jerárquicos. 

Los SGBD relacionales se basan en el modelo de datos jerárquico. El modelo

jerárquico es similar al modelo de redes, en el sentido en que los datos y las
relaciones entre los datos se representan mediante registros y enlaces,
respectivamente. Éste se diferencia del modelo de redes en que los registros
se organizan como colecciones de árboles en lugar de grafos dirigidos. En la
siguiente figura se presenta un ejemplo de base de datos jerárquica. 

Modelo de datos relacionales. 

 Basados en el modelo relacional, los datos se describen como relaciones que se

suelen representar como tablas bidimensionales consistentes en filas y columnas.
Cada fila (tupla, en terminología relacional) representa una ocurrencia. Las
columnas (atributos) representan propiedades de las filas. 

Cada tupla se identifica por una clave primaria o identificadora. 

Modelo orientado a objetos. 

Una de las novedades más prometedoras y más desarrolladas comercialmente de
los nuevos SGBD, son los basados en un nuevo modelo de datos conocido como
modelo orientado a objetos. 

2.1.3 PRODUCTOS

SGBD libres

 MySQL Licencia Dual, depende el uso (no se sabe hasta cuando, ya que la
compro Oracle). Sin embargo, existen 2 versiones: una gratuita que sería
equivalente a la edición “express” SQL server de Windows y otra más
completa de pago, ese pago se haría en la licencia de ella ya que permitiría
usarse en otras distribuciones sin usar la licencia GNU.

 PostgreSQL (http://www.postgresql.org Postgresql) Licencia 

 BSDFirebird basada en la versión 6 de InterBase, Initial Developer’s

PUBLIC LICENSE Version 1.0.

 SQLite (http://www.sqlite.org SQLite) Licencia Dominio PúblicoDB2

Express-C (http://www.ibm.com/software/data/db2/express/)

 Apache Derby (http://db.apache.org/derby/)

SGBD no libres

 Advantage Database

 dBase

 FileMaker

 Fox Pro

 IBM DB2 Universal Database (DB2 UDB)

 IBM Informix
  Interbase de CodeGear, filial de Borland

 MAGIC

 Microsoft Access

 Microsoft SQL Server

 NexusDB

 Open Access

 Oracle

 Paradox

 PervasiveSQL

 Progress (DBMS)

 Sybase ASE

 Sybase ASA

 Sybase IQ

 WindowBase

 IBM IMS Base de Datos Jerárquica

 CA-IDMS

SGBD no libres y gratuitos

 Microsoft SQL Server Compact Edition Basica

 Sybase ASE Express Edition para Linux (edición gratuita para Linux)

 Oracle Express Edition 10

2.2 Estándar ODMG

Este Modelo estándar ODMG, especifica los elementos que se definirán, y en qué
manera se hará, para la consecución de persistencia en las Bases de datos
orientadas a objetos que soporten el estándar. Consta de un lenguaje de definición
de objetos, ODL, que especifica los elementos de este modelo. Un grupo de
representantes de la industria de las bases de datos formaron el ODMG (Object
Database Management Group) con el propósito de definir estándares para los
SGBD orientados a objetos. Este grupo propuso un modelo estándar para la
semántica de los objetos de una base de datos. Su ultima versión, ODMG 3.0,
apareció en enero de 2000.

El estándar ODMG es un producto de consorcio internacional OMG, el cual

principalmente proporciona técnicas orientadas a objetos para la ingeniería
de software. Sus estándares pueden ser aceptados por empresas certificadas
como ISO. El estándar OSMG es el modelo para la semántica de los objetos de
una base de datos. Permite portar tanto los diseños como las implementaciones
en diversos sistemas compatibles.

ODMG está compuesto por:

 Modelo de Objeto

El modelo de objetos ODMG permite que tanto los diseños, como las
implementaciones, sean portables entre los sistemas que lo soportan. Dispone de
las siguientes primitivas de modelado:

Los componentes básicos de una base de datos orientada a objetos son los
objetos y los literales. Un objeto es una instancia autocontenida de una entidad de
interés del mundo real. Los objetos tienen algún tipo de identificador unico. Un
literal es un valor específico, como “Amparo” o 36. Los literales no tienen
identificadores. Un literal no tiene que ser necesariamente un solo valor, puede ser
una estructura o un conjunto de valores relacionados que se guardan bajo un solo
nombre. Los objetos y los literales se categorizan en tipos. Cada tipo tiene un
dominio específico compartido por todos los objetos y literales de ese tipo. Los
tipos también pueden tener comportamientos. Cuando un tipo tiene
comportamientos, todos los objetos de ese tipo comparten los mismos
comportamientos. En el sentido práctico, un tipo puede ser una clase de la que se
crea un objeto, una interface o un tipo de datos para un literal (por ejemplo, integer
). Un objeto se puede pensar como una instancia de un tipo. Lo que un objeto
sabe hacer son sus operaciones. Cada operación puede requerir datos de entrada
(parámetros de entrada) y puede devolver algún valor de un tipo conocido. Los
objetos tienen propiedades, que incluyen sus atributos y las relaciones que tienen
con otros objetos. El estado actual de un objeto viene dado por los valores
actuales de sus propiedades. Una base de datos es un conjunto de objetos
almacenados que se gestionan de modo que puedan ser accedidos por múltiples
usuarios y aplicaciones. La definición de una base de datos está contenida en un
esquema que se ha creado mediante el lenguaje de definición de objetos ODL
(Object Definition Language) que es el lenguaje de manejo de datos que se ha
definido como parte del estándar propuesto para las bases de datos orientadas a
objetos.

 Lenguaje de definición de objeto ODL

ODL es un lenguaje de especificación para definir tipos de objetos para sistemas

compatibles con ODMG. ODL es el equivalente del DDL (lenguaje de definición de
datos) de los SGBD tradicionales. Define los atributos y las relaciones entre tipos,
y especifica la signatura de las operaciones. La sintaxis de ODL extiende el
lenguaje de definición de interfaces (IDL)de la arquitectura CORBA (Common
Object Request Broker Architecture).

 Lenguaje de Consulta de objetos OQL

OQL es un lenguaje declarativo del tipo de SQL que permite realizar consultas de
modo eficiente sobre bases de datos orientadas a objetos, incluyendo primitivas
de alto nivel para conjuntos de objetos y estructuras. Está basado en SQL-92,
proporcionando un súper conjunto de la sintaxis de la sentencia SELECT.OQL no
posee primitivas para modificar el estado de los objetos ya que las modificaciones
se pueden realizar mediante los métodos que é
́ stos poseen. La sintaxis básica de
OQL es una estructura SELECT...FROM...WHERE..., como en SQL.

2.3 Identidad y Estructura de Objetos

Identidad

La identidad es la propiedad que permite diferenciar a un objeto y distinguirse de

otros. Generalmente esta propiedad es tal, que da nombre al objeto. Tomemos por
ejemplo el "verde" como unobjeto concreto de una clase color; la propiedad que da
identidad única a este objeto es precisamente su "color" verde. Tanto es así que
para nosotros no tiene sentido usar otro nombre para el objeto que no sea el valor
de la propiedad que lo identifica.

En programación la identidad de los objetos sirve para comparar si dos objetos

son iguales o no. No es raro encontrar que en muchos lenguajes de
programación la identidad de un objeto esté determinada por la dirección
de memoria de la computadora en la que se encuentra el objeto, pero este
comportamiento puede ser variado redefiniendo la identidad del objeto a otra
propiedad.

Estructura 

Es la disposición, distribución y orden de las partes del cuerpo de una cosa

determinada inanimada, que puede ser perceptible por algún sentido, y se puede
accionar sobre ella.

Desglosando la definición, es de considerar que objeto es una cosa, que puede

ser material real (materia con una forma definida, que se puede percibir con algún
sentido (vista, tacto, etc.), ejemplo una mesa, o una manzana), o abstracta (por
ejemplo una idea, o un proyecto que todavía no se concreta o se hace real), y que
esa cosa u objeto, está conformado por partes (aún lo más pequeño, como el
átomo, se forma por un conjunto de elementos), y las mismas están dispuestas,
ordenadas, o acomodadas de tal forma que conforman un cuerpo, ya sea que
forme parte de la naturaleza, o haya sido creado por el ser humano (en este caso
entonces es una obra de ingenio).

2.4 Encapsulamiento, Herencia y Polimorfismo en BDOO

Encapsulamiento
El encapsulamiento consiste en unir en la Clase las características y
comportamientos, esto es, las variables y métodos. Es tener todo esto es una sola
entidad. En los lenguajes estructurados esto era imposible. Es evidente que el
encapsulamiento se logra gracias a la abstracción y el ocultamiento. La utilidad del
encapsulamiento va por la facilidad para manejar la complejidad, ya que
tendremos a las Clases como cajas negras donde sólo se conoce el
comportamiento, pero no los detalles internos, y esto es conveniente porque nos
interesará será conocer qué hace la Clase, pero no será necesario saber cómo lo
hace.

Herencia 

 A través de ella los diseñadores pueden crear nuevas clases partiendo de una
clase o de una jerarquía de clases preexistente (ya comprobadas y verificadas)
evitando con ello el rediseño, la modificación y verificación de la parte ya
implementada. La herencia facilita la creación de objetos a partir de otros ya
existentes e implica que una subclase obtiene todo el comportamiento (métodos) y
eventualmente los atributos (variables) de su superclase.

Es la relación entre una clase general y otra clase más específica. Por ejemplo: Si
declaramos una clase párrafo derivada de una clase texto, todos los métodos y
variables asociadas con la clase texto, son automáticamente heredados por la
subclase párrafo.

La herencia es uno de los mecanismos de los lenguajes de programación

orientada a objetos basados en clases, por medio del cual una clase se deriva de
otra de manera que extiende su funcionalidad. La clase de la que se hereda se
suele denominar clase base, clase padre, superclase, clase ancestro (el
vocabulario que se utiliza suele depender en gran medida del lenguaje de
programación).

En los lenguajes que cuentan con un sistema de tipos fuerte y estrictamente

restrictivo con el tipo de datos de las variables, la herencia suele ser un requisito
fundamental para poder emplear el Polimorfismo, al igual que un mecanismo que
permita decidir en tiempo de ejecución qué método debe invocarse en respuesta a
la recepción de un mensaje, conocido como enlace tardío (late binding) o enlace
dinámico (dynamic binding).

Polimorfismo

se refiere a la propiedad por la que es posible enviar mensajes sintácticamente

iguales a objetos de tipos distintos. El único requisito que deben cumplir los
objetos que se utilizan de manera polimórfica es saber responder al mensaje que
se les envía.

La apariencia del código puede ser muy diferente dependiendo del lenguaje que
se utilice, más allá de las obvias diferencias sintácticas.

En lenguajes basados en clases y con un sistema de tipos de datos fuerte

(independientemente de si la verificación se realiza en tiempo de compilación o de
ejecución), es posible que el único modo de poder utilizar objetos de manera
polimórfica sea que compartan una raíz común, es decir, una jerarquía de clases,
ya que esto proporciona la compatibilidad de tipos de datos necesaria para que
sea posible utilizar una misma variable de referencia (que podrá apuntar a objetos
de diversas subclases de dicha jerarquía) para enviar el mismo mensaje (o un
grupo de mensajes) al grupo de objetos que se tratan de manera polimórfica.

No obstante, algunos lenguajes de programación (Java, C++) permiten que dos

objetos de distintas jerarquías de clases respondan a los mismos mensajes, a
través de las denominadas interfaces (esta técnica se conoce como composición
de objetos). Dos objetos que implementen la misma interfaz podrán ser tratados
de forma idéntica, como un mismo tipo de objeto, el tipo definido por la interfaz.
Así, distintos objetos podrán intercambiarse en tiempo de ejecución –siempre que
sean del mismo tipo–, y además con dependencias mínimas entre ellos. Por estos
motivos se considera un buen principio de diseño en programación orientada a
objetos el favorecer la composición de objetos frente a la herencia de clases. 1

En Java las interfaces se declaran mediante la palabra clave "interfaces “Estas se

utilizan para lograr la necesaria concordancia de tipos que hace posible el
polimorfismo, también como un contrato que debe cumplir cualquier clase que
implemente una cierta interfaz, y como una forma de documentación para los
desarrolladores. A veces, en la literatura específica sobre Java se habla de
"herencia y polimorfismo de interfaces", lo que no concuerda con los conceptos de
la programación orientada a objetos porque una clase que implementa una interfaz
sólo obtiene su tipo de datos y la obligación de implementar sus métodos, no copia
comportamiento ni atributos. Esta terminología puede llevar a confusión, puesto
que en Java a menudo se utiliza la mal llamada "herencia de interfaces" para dotar
a una clase de uno o varios tipos adicionales, lo que, unido a la composición, evite
la necesidad de la herencia múltiple y favorezca una utilización más amplia del
polimorfismo.

2.5 Persistencia, Concurrencia y Recuperación en BDOO

Persistencia
Esta se refiere a la capacidad de manipular directamente los datos almacenados
en una base de datos usando un lenguaje de programación orientado a objetos.
Esto contrasta con una base de datos utilizada por SQL o una interfaz utilizada por
ODBC o JDBC. Utilizando un objeto de base de datos significa que se puede tener
un mayor rendimiento y se aminora la escritura de código. Con la persistencia la
manipulación de objetos se realiza directamente por el lenguaje de programación
de la misma manera que en la memoria, sin persistencia de objetos. Esto se logra
mediante el uso inteligente de almacenamiento en caché.
Concurrencia
Los SMBDOO deben poder ser accesibles por múltiples usuarios. Cuando una
aplicación está accesando a una sección de la base de datos, otras aplicaciones
deben poder acceder a otras secciones de la base de datos. La concurrencia
permite a los usuarios cooperar y colaborar en una aplicación. Los mecanismos de
control de concurrencia son necesarios para reforzar las propiedades de las
transacciones (ACID). Los modos básicos de control de concurrencia son: Modo
Pesimista Modo optimista Modo mixto Modo semi-optimista. El modo pesimista
obliga a una transacción a esperar a que se resuelva el conflicto que pueda o
ponga en riesgo la concurrencia para dejarle continuar cuando el conflicto halla
sido resuelto. 
El modo optimista deje correr la transacción como si no ocurriera ningún conflicto y
resuelve este al final del commit, generalmente se emplea usando estampas de
tiempo y copias de los elementos de la transacción. El modo mixto combina
diferentes controles de concurrencia a diferentes objetos y tipos de datas en una
misma transacción. El modo semi-optimista es una variante del modo mixto que no
detiene a la transacción hasta que esta termina. Los principales mecanismos de
control de concurrencia son tres: Candados que prohíben accesos que puedan
provocar conflictos de acceso Estampas de tiempo.- estas permiten impedir
violaciones a los datos. Guardar múltiples versiones de los objetos de datos.

Recuperación

Con recuperación nos referimos al proceso de aplicación de consistencia después

de que una transacción a abortado como resultado de fallas de hardware o
problemas de comunicación. Las fallas del sistema, tanto de hardware como de
software no deben repercutir en estados de inconsistencia de la base datos. La
recuperación es la técnica que asegura que eso no ocurra. La recuperación puede
ser total o parcial dependiendo de las circunstancias, de la recuperabilidad.
 CONCLUSION
Como conclusión esta investigación nos presentó grandes temas que abarcan en
el tema principal, que es los sistemas de bases de datos orientado a objetos, este
tema nos demuestra y nos dio a conocer cómo se pueden diseñar, estructurar y
elaborar los sistemas de bases de datos orientado a objetos. El principal objetivo
es crear bases de datos que contengan las características, diseños y entre otros,
basados a objetos del mundo real, lo que lleva a definir grandes cualidades de los
SGBDOO. Como también pudimos comprender algunos temas que se destacaron
dentro de la investigación, como son el modelo de datos orientado a objetos, en el
cual menciona que se representa cierta información y se modelan ciertos aspectos
y así como este hay temas importantes.

REFERENCIAS BIBLIOGRAFICAS

 Oracle, (2010). Documentación oficial del Administrador de Base de Datos.

Disponible en: http://www.oracle.com/technology/documentation/index.html
 Ramírez A. Elmasri, Shamkant B. Navathe, Fundamentos de Sistemas de
Bases de Datos, 3ª. Edición, Addison Wesley, 2002.