qwertyuiopasdfghjklzxcvbnmqwe

rtyuiopasdfghjklzxcvbnmqwertyui
opasdfghjklzxcvbnmqwertyuiopa
sdfghjklzxcvbnmqwertyuiopasdfg
INSTITUTO TECNOLÓGICO DE
CULIACÁN
hjklzxcvbnmqwertyuiopasdfghjklz
TEMAS SELECTOS
DE BASES DE
xcvbnmqwertyuiopasdfghjklzxcv
DATOS
bnmqwertyuiopasdfghjklzxcvbnm
Nombre del trabajo: Estándar

qwertyuiopasdfghjklzxcvbnmqwe
ODMG y Bases de datos Objeto-
Relacional

rtyuiopasdfghjklzxcvbnmqwertyui
Alumno: Robles Smith Amilcar
Augusto.
opasdfghjklzxcvbnmqwertyuiopa
Profesor: Clemente García
Gerardo
sdfghjklzxcvbnmqwertyuiopasdfg
miércoles, 01 de diciembre de 2010

hjklzxcvbnmqwertyuiopasdfghjklz
xcvbnmqwertyuiopasdfghjklzxcv
bnmqwertyuiopasdfghjklzxcvbnm
qwertyuiopasdfghjklzxcvbnmqwe
rtyuiopasdfghjklzxcvbnmrtyuiopa
Estándar ODMG

ODMG (Object Database Mangement Group) es el grupo de fabricantes de SGBDOO

(sistemas Gestores de Bases de datos Orientadas a Objetos) que propuso el estándar ODM-93 en
1993; en 1997 evolucionó a ODMG-2.0 y en enero de 2000 se publicó la última versión ODMG 3.0.
El uso del estándar proporciona portabilidad (que se pueda ejecutar sobre sistemas distintos),
interoperabilidad (que la aplicación pueda acceder a varios sistemas diferentes) y además permite
que los usuarios puedan comparar entre distintos sistemas comerciales.

Este modelo 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.

El modelo Estándar de ODMG

Modelo de objetos:
El modelo de objetos ODMG permite que tanto los diseños, como las implementaciones, sean
portables entre los sistemas que lo soportan.
• Los componentes básicos de una base de datos orientada a objetos son objetos y literales.
Un objeto es una instancia autocontenida de una entidad de interés del mundo real.
• Los objetos tienen algún tipo de identificador único. Un literal es un valor específico, por
ejemplo, “Amparo” o 36. Los literales no tienen identificadores y no tienen que ser
necesariamente un solo valor, puede ser una estructura o un conjunto de valores
relacionados que se guardan bajo un nombre.
• Los objetos y 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, que también comparten todos los objetos del mismo. 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. Las propiedades son sus atributos y las relaciones.
• 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 pueden 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, lo que equivaldría en una base de datos relacional a la DDL(Data Definition
Languaje).

Objetos:
Los tipos de tipo colección (para las clases contenedor) son:

• Set<tipo>: Grupo desordenado de objetos del mismo tipo. No se permiten duplicados.

• Bag<tipo>: Grupo desordenado de objetos del mismo tipo. Se permiten duplicados.
• List<tipo>: Grupo ordenado de objetos del mismo tipo. Se permite duplicados.

miércoles, 01 de diciembre de 2010

 • Array<tipo>: Grupo ordenado de objetos del mismo tipo que se puede acceder por
su posición. El tamaño es dinámico.
• Dictionary<clave,valor>: índice. Formado por las clavez ordenadas, emparejada con un
solo valor.

De tipo estructurado:
Date: fecha del calendario
Time: hora.
Timestamp: hora de una fecha.
Interval: período de tiempo.

Literales:
No tienen identificadores y no pueden aparecer solos como objetos, están dentro de los objetos y
no pueden referenciarse de modo individual.
• Boolean: verdadero o falso.
• Short: entero con signo de 8 o 16 bits.
• Long: entero con signo de 32 o 64 bits.
• Unsigned short: entero sin signo de 8 o 16 bits.
• Unsigned long: entero sin signo de 32 o 64 bits.
• Float: valor real en coma flotante de simple precisión.
• Double: valor real en coma flotante de doble precisión
• Octet: almacén de 8 bits.
• Char: carácter ASCII o UNICODE.
• String: cade de caracteres.
• Enum: tipo enumerado donde los valores se especifican explícitamente cuando se declara
el tipo.
• Literales estructurales contienen un número fijo de elementos heterogéneos. Cada
elemento es un par <nombre,valor> donde valor puede ser cualquier tipo literal. Tipos
estructurados son: date, time, timestamp, interval y struct.

Los de colección son: set<tipo>, bag<tipo>, listo<tipo>, array<tipo> y dictionary<clave,valor>.

Tipos
Una interface es una especificación del comportamiento abstracto de un tipo de objeto y
contiene las asignaturas de las operaciones. No se pueden crear objetos a partir de ella
(equivalente a una clase abstracta).

Una clase es una especificación del comportamiento abstracto y del estado abstracto de un
tipo de objeto. A partir de ellas se pueden crear instancias de objetos individuales (equivalente a
una clase concreta). Soporta la herencia simple y la herencia múltiple mediante las interfaces. Se
suelen utilizar para especificar operaciones abstractas que pueden ser heradas por las clases o por
otras interfaces: Herencia de comportamiento. Requiere que el supertipo sea una interface y el
subtipo sea una clase o un interface.

Se puede hacer referencia a los subtipo como su supertipo. Los subtipo se pueden
especializar como sea necesario añadiéndoles comportamientos. Los subtipos de un subtipo
especializado heredan también los comportamientos añadidos.

La relación extiende (extends) para iindicar la herencia de estado y de comportamiento. La

clase puede extender a otra clase. Las clases de más abajo en la jeraquía heredan todo lo que sus
supertipos heredan de las clases que tienen por encima.

Puede tener una o más claves (key), es un identificador único. Con una sola propiedad es
una clave simple y con varias propiedades es una clave compuesta.

miércoles, 01 de diciembre de 2010

 La representación es una estructura de datos dependiente de un lenguaje de programación
que contiene las propiedades del tipo.

Los detalles de las operaciones de un tipo se especifican mediante un conjunto de

métodos. Un tipo puede incluir métodos que nunca se ven desde fuera del tipo. Los métodos se
escribirán en el mismo lenguaje de programación utilizado.

Propiedades
Atributos: Define del tipo de un objeto. No tiene identificador, toma como valor un literal o el
identificador de un objeto.
Relaciones: Se definen entre tipos. Sólo soporta relaciones binarias (1:1, 1:n, n:m). Define caminos
transversales en la interface de cada dirección.
En el lado del muchos los objetos pueden estar desordenados (set o bag) u ordenados (list).

Métodos
Son funciones o procedimientos que se pueden declarar en la definición de un tipo de objeto para
implementar el comportamiento que se desea para dicho tipo de objeto. El método miembro se
utiliza para ganar acceso a los datos de una instancia de un objeto.

Transacciones
Son unidades lógicas de trabajo que llevan a la base de datos de un estado consistente a otro
estado consistente. Todos los accesos, creación, modificación y borrado de objetos persistentes se
deben realizar dentro de una transacción.

ODL(Object Definition Languaje, Lenguaje de Definición de Objetos):

ODL es un lenguaje de especificación para definir tipos de objetos para sistemas complejos
compatibles con ODMG. Es el equivalente de DDL (Data Definition Languaje o lenguaje de
definición de datos) de los DBMS 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).
Las declaraciones de atributos son sintácticamente idénticas las declaraciones de miembros de C+
+.

OQL(Object Query Languaje, Lenguaje de Consulta de Objetos):

Permite realizar consultas de modo eficiente sobre bases de datos orientadas a objetos. Basado en
SQL-92.
La sintaxis básica de OQL es una structura SELECT… FROM… WHERE… como en SQL:
SELECT d.nombre
FROM d in departamentos
WHERE d.escuela=”Ingeniería”;

En las consultas se necesita un punto de entrada que es la extensión de una clase. Además es
necesario utilizar una variable iteradora que vaya tomando valores en los objetos de la colección.
Éstas se pueden especificar de estas formas:

D in departamentos
Departamentos d
Departamentos as d

Una consulta no debe seguir la estructura SELECT obligatoriamente, el nombre de cualquier objeto
persistente es una consulta de por sí:
Departamentos;

miércoles, 01 de diciembre de 2010

DBOR (Database Object Relational)
Las Base de Datos Objeto Relacional son una extensión de las base de datos
relacional tradicional, a la cual se le proporcionan características de la programación orientada a
objetos. Los ejemplos mostrados están en base al estándar SQL99.

Uno de los problemas de las bases de datos relacionales está relacionado con limitaciones
en representaciones (elementos complejos que están presentes en muchos dominios como
gráficos son difíciles de representar). Por otro lado, las bases de datos orientadas a objetos no son
lo suficientemente maduras para ser aceptadas, y es realmente difícil convertir a los especialistas
relacionales y convencer a los manejadores para adoptar este nuevo paradigma con todos los
posibles riesgos involucrados.

Desde este punto de vista. El paradigma objeto-relacional propone un buen compromiso

entre ambos mundos. Las bases de datos Objeto Relacional combinan características de las
bases de datos tradicionales(Modelo de datos, recuperación seguridad, concurrencia, lenguaje de
alto nivel, etc) con los principios orientados a objetos. (p.e. Encapsulamiento, generalización,
agregación, polimorfismo, herencia, etc.)Estos productos ofrecen la posibilidad de definer clases o
tipos de datos abstractos, en adición de tablas, llaves primarias y foráneas, y restricciones, como lo
hacen las bases de datos relacionales.

Un objetivo de las bases de datos objeto-relacionales es de llenar ola brecha entre las
técnicas de modelado de datos conceptuales como el diagrama entidad-relacion. Otro objetivo
relacionado es de llenar la brecha entre bases de datos relacionales y las técnicas de modelado
orientadas a objetos utilizadas en lenguajes de programación como Java, C++, Visual Basic.NET o
C#. Sin embargo, una alternativa más popular para alcanzar dicho objetivo es utilizar una base de
datos relacional estándar con alguna forma de Mapeado Objeto-Relacional.

Mientras los DBMS relacionales o DBMS-SQL se enfocan en el manejo de datos eficiente,

retirados de un conjunto de tipos de datos limitados, una base de datos objeto relacional permite a
los desarrolladores de software el integrar sus propios tipos y los métodos que se aplican a ellos en
los DBMS. Los DMBSOR permiten a los desarrolladores incrementar el nivel de abstracción al cual
ellos ven el dominio del problema.

Relaciones Anidadas
Nacen como una extensión del modelo relacional, en el que los dominios de dicha base de datos
ya no son sólo atómicos, por lo que no se cumple la 1FN, debido a que las tuplas también pueden
ser una relación, que llevará a la creación de una relación de relaciones. De este modo, se genera
la posibilidad de guardar objetos más complejos en una sola tabla con referencias a otras
relaciones, con lo que se acerca más al paradigma de programación orientada a objetos.

Tipos Complejos
Tipos: Dentro de lo que llamamos tipos de datos complejos podemos definir los siguientes:
Colecciones: También conocidos como conjuntos, este tipo de datos clasifican los arreglos y los
conjuntos en que los elementos pueden aparecer varias veces.
Tipos estructurados: Los tipos estructurados permiten representación directa de los atributos
compuestos en los diagramas entidad-relación.
Objetos de gran tamaño: Desde ya hace varios años que se necesita almacenar datos con
atributos muy grandes (Varios MB), como libros, canciones, etc. E incluso aún más grandes; como
mapas de alta resolución, video, etc. que puede llegar fácilmente a los GB.

Herencia
La herencia puede hallarse en el nivel de los tipos o en el nivel de las tablas. En primer lugar se
considerará la herencia de los tipos y después en el nivel de las tablas:
Herencia de tipos: Los tipos derivados heredan los atributos de superclase; los métodos también se
heredan por sus subtipos, al igual que los atributos. Sin embargo, un subtipo puede redefinir el

miércoles, 01 de diciembre de 2010

efecto de un método declarándolo de nuevo, y esto será lo que se conoce como sobre escritura
(overriding) del método.
Ejemplo: create type Persona (nombre varchar(20), direccion varchar(20)) , Con esto se necesita
definir varios tipos de personas: create type Estudiante under Persona (curso varchar(20),
departamento varchar(20)) create type Profesor under Persona (sueldo integer, departamento
varchar(20)) ;
Herencia de tablas: Cada tabla almacena la clave primaria, que se puede heredar de una tabla
padre; y los atributos definidos localmente. Los atributos heredados, aparte de la clave primaria, no
será necesario guardarlos, podrán obtenerse mediante una reunión con la super tabla basada en la
clave primaria. Por lo que cada tabla almacena todos los atributos heredados y definidos
localmente. Cuando se inserta una tupla, se almacena sólo en la subtabla en la que se inserta y su
presencia se infiere en cada supertabla. El acceso a todos los atributos de una tupla es más rápido,
dado que no se requiere una reunión:
Ejemplo: create table estudiantes of Estudiante under persona;
Funciones: Dentro de la base de datos se pueden definir métodos y procedimientos, como Java,
C++, etc. Algunos sistemas de base de datos ofrecen sus propios lenguajes, como es el caso de
POSTGRESQL, que integra el lenguaje PL/PQSL.
Ejemplo:
CREATER FUNCTION contar_hijos(RUT varchar(12)) return integer Begin declare cuenta integer;
Select count(hijo) into cuenta from hijos where usuario.RUT = RUT Return cuenta; End Esta
función se ocupa del siguiente modo:
Select nombres from usuario where contar_hijos (Rut) > 0;
También se permite el polimorfismo, que quiere decir que pueden existir métodos con el mismo
nombre, pero con distinta cantidad de argumentos. .

miércoles, 01 de diciembre de 2010

Conclusiones

Con base al trabajo realizado se puede concluir dos cosas:

El estándar ODMG, Object Database Management Group, es utilizado

para definir el grupo de personas y empresas encargadas de desarrollar el modelo
de objetos para persistencia, y para la definición del estándar del lenguaje de
consulta de objetos, siendo su principal objetivo definir las especificaciones para
las bases de datos orientadas a objetos, con el fin de que se pueda ofrecer
portabilidad a la manipulación de datos y lenguajes de consulta.

Las bases de datos objeto-relacionales vienen a resolver el problema que

tienen en ocasiones las bases de datos relacionales tradicionales, surgiendo
como un intermediario que combina los beneficios de las bases de datos
relacionales y las orientadas a objetos, ya que es posible incluir, en los lenguajes
de consultas las características del modelo orientado a objetos. Éstas sirven como
un almacenamiento persistente para los lenguajes orientados a objetos,
incluyendo conceptos de las bases de datos relacionales como llaves primarias,
foráneas, etc.

Bibliografía

http://www.tutoriales.itsa.edu.mx/TopicosAvanzadosBD/index.php?mod=elestandar&ban=0

http://www.odbms.org/ODMG/

http://en.wikipedia.org/wiki/ODMG

http://wapedia.mobi/en/Object-relational_database_management_system

miércoles, 01 de diciembre de 2010