Download modelo orientado a objetos

UNIVERSIDAD LATINA
BASES DE DATOS
MODELO ORIENTADO A OBJETOS
Retos actuales de los sistemas manejadores de bases de
datos
MODELOS ORIENTADOS A OBJETOS

Surgió en los años 90s.

Unificación de técnicas = UML.
“el MOO es la construcción de modelos de un sistema
por medio de la identificación y especificación de un
conjunto de objetos relacionados, que se comportan y
colaboran entre sí de acuerdo a los requerimientos
establecidos para el sistema de objetos.”

Tendencias actuales en la tecnología de
bases de datos
Mundo real
Análisis y
diseño
Modelo
Código
Programa
De BD
Orientación a objetos
Se
emplean clases para definir las entidades
Clase -> Define estructura y compotamiento de
objetos


Esquema OO -> Conjunto de clases.
Modelo -> Aspecto de la realidad y se construye de
modo que nos ayude a comprender a esta.

DIMENCIONES ORIENTADAS A
OBJETOS
Dimensiones que
describen un sistema
de objetos
 Dimensión estructural de los
objetos -> Propiedades estáticas
 Dimensión dinámica del
comportamiento -> Propiedades
activas, comportamiento individual y
colaboración entre objetos.
 Dimensión funcional de los
requerimientos -> Propiedades de
transformación del sistema
ACTIVIDADES MODELOS ORIENTADOS
A OBJETOS

Las actividades que se deben seguir para llevar un MOO son:

Identificar clases, objetos y atributos

Asociar estáticamente los objetos

Describir el comportamiento de los objetos

Definir la colaboración del comportamiento de los objetos

Organizar las clases en jerarquías de herencia
Agregar
abstracción

y/o particionar las clases por niveles de
PERSISTENCIA
•
Se entiende por persistencia (en programación orientada a objetos)
como el mecanismo o la acción de preservar la información de un
objeto de forma permanente (guardar), pero a su vez también se
refiere a poder recuperar la información del mismo (leer) para
que pueda ser nuevamente utilizada.
•
En el caso de persistencia de objetos la información que persiste en
la mayoría de los casos son los valores que contienen los atributos en
ese momento, no necesariamente la funcionalidad que proveen sus
métodos.
ANTECEDENTES
•
- Primera generacion.- B-Base (1986), GemStone(1987). Son
considerados como lenguajes orientados a objetos con persistencia.
•
- Segunda generación.- Ontos(1989), Object Design, Objetivity, etc.
La caracteristica principal es que utilizan una arquitectura clienteservidor.
•
- Tercera generación. Itasca(1990), etc. Son verdaderos SMBDOO,
con motores que gestionan objetos y lenguajes como ODL, OML,
OQL.
DEFINICIONES
•
- Bases de datos orientadas a objetos: Es una colección de objetos
en los que sus estados, comportamientos y relaciones son definidas
de acuerdo con un modelo de datos orientado a objetos.
•
- Sistema Manejador de Bases de Datos Orientado a Objetos: Es
un sistema de Base de Datos que permite la definición y manipulación
de una Base de Datos Orientada a Objetos.
CARACTERISTICAS
•
Del
SMBDOO.Persistencia,
Concurrencia,
Almacenamiento Secundario, Consultas.
•
De la orientación a objetos.- Manejo de complejos objetos,
Indentidad, Encapsulación, Herencia, Tipos o Clases, Sobrecarga,
Extensibilidad, Completitud Computacional..
Recuperación,
Estándar ODMG
- ODMG (Object Data Management Group)
- Lenguajes de Especificacion de Objetos (ODL)
- Lenguajes de Manipulación de Objetos (OML)
- Lenguajes de Consulta (OQL)
Bindings para lenguajes de programación OO como C++, Smalltalk o
Java
-
un binding es una adaptación de una biblioteca para ser usada en un
lenguaje de programación distinto de aquél en el que ha sido escrita
LENGUAJES OO
•
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 ORIENTACIÓN A OBJETOS
•
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.
PRINCIPIOS DE ORIENTACIÓN A 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.
PRINCIPIOS DE ORIENTACIÓN A OBJETOS
•
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.
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.
BASES DE DATOS ORIENTADAS A OBJETOS (BDOO)
•
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
Semestre
Grupo
CLASE ALUMNO
Número
Económico
Plaza
RFC
CLASE MAESTRO
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.
PRIMER INTENTO DE ESTANDARIZACIÓN: ODMG-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.
PRIMER INTENTO DE ESTANDARIZACIÓN: ODMG-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.