Sistema de Base de Datos Orientadas a Objetos – Unidad II


El siguiente documento tiene la

EL MODELO DE DATOS ORIENTADO A OBJETOS

 

El modelo de datos orientado a objetos es una extensión del paradigma de programación orientado a objetos. Los objetos entidad que se utilizan en los programas orientados a objetos son análogos a las entidades que se utilizan en las bases de datos orientadas a objetos puras, pero con una gran diferencia: los objetos del programa desaparecen cuando el programa termina su ejecución, mientras que los objetos de la base de datos permanecen. A esto se le denomina persistencia.

 

Relaciones

Las bases de datos relacionales representan las relaciones mediante las claves ajenas. No tienen estructuras de datos que formen parte de la base de datos y que representen estos enlaces entre tablas. Las relaciones se utilizan para hacer concatenaciones (join) de tablas. Por el contrario, las bases de datos orientadas a objetos implementan sus relaciones incluyendo en cada objeto los identificadores de los objetos con los que se relaciona.

 

Un identificador de objeto es un atributo interno que posee cada objeto. Ni los programadores, ni los usuarios que realizan consultas de forma interactiva, ven o manipulan estos identificadores directamente. Los identificadores de los objetos los asigna el SGBD y es el, el único que los utiliza.

El identificador puede ser un valor arbitrario o puede incluir la información necesaria para localizar el objeto en el fichero donde se almacena la base de datos. Por ejemplo, el identificador puede contener el número de la página del fichero donde se encuentra almacenado el objeto, junto con el desplazamiento desde el principio de la página. Hay dos aspectos importantes a destacar sobre este método de representar las relaciones entre datos: Para que el mecanismo funcione, el identificador del objeto no debe cambiar mientras  este forme parte de la base de datos. Las únicas relaciones que se pueden utilizar para consultar la base de datos son aquellas que se han predefinido almacenando en atributos los identificadores de los objetos relacionados. Por lo tanto, una base de datos orientada a objetos pura es navegacional, como los modelos prerrelacionales (el modelo jerárquico y el modelo de red). De este modo se limita la flexibilidad del programador/usuario a aquellas relaciones predefinidas, pero los accesos que siguen estas relaciones presentan mejores prestaciones que en las bases de datos relacionales porque es más rápido seguir los identificadores de los objetos que hacer operaciones de concatenación (join). El modelo orientado a objetos permite los atributos multivaluados, agregaciones a las que se denomina conjuntos (sets) o bolsas (bags). Para crear una relación de uno a muchos, se define un atributo en la parte del uno que sera de la clase del objeto con el que se relaciona. Este atributo contendrá el identificador de objeto del padre.

La clase del objeto padre contendrá un atributo que almacenara un conjunto de valores: los identificadores de los objetos hijo con los que se relaciona. Cuando el SGBD ve que un atributo tiene como tipo de datos una clase, ya sabe que el atributo contendrá un identificador de objeto. Las relaciones de muchos a muchos se pueden representar directamente en las bases de datos orientadas a objetos, sin necesidad de crear entidades intermedias. Para representar la relación, cada clase que participa en ella define un atributo que contendrá un conjunto de valores de la otra clase con la que se relacionara. Aunque el hecho de poder representar relaciones de muchos a muchos parece aportar muchas ventajas, hay que tener mucho cuidado cuando se utilizan. En primer lugar, si la relación tiene datos, será necesario crear una entidad intermedia que contenga estos datos. Por ejemplo, en la relación de los artículos con los proveedores, en donde cada proveedor puede tener un precio distinto para un mismo artículo. En este caso, la relación de muchos a muchos se sustituye por dos relaciones de uno a muchos, como se haría en una base de datos relacional. En segundo lugar, se puede diseñar una base de datos que contiene relaciones de muchos a muchos en donde o bien se pierde información, o bien se hace imposible determinar las relaciones con precisión.

 

También en estos casos la solución es incluir una entidad intermedia que represente la relación. Ya que el paradigma orientado a objetos soporta la herencia, una base de datos orientada a objetos también puede utilizar la relación “es un” entre objetos. Por ejemplo, en una base de datos para un departamento de recursos humanos habrá una clase genérica Empleado con diversos atributos: nombre, dirección, número de la seguridad social, fecha de contrato y departamento en el que trabaja. Sin embargo, para registrar el modo de pago de cada empleado hay un dilema. No a todos los empleados se les paga del mismo modo: a algunos se les paga por horas, mientras que otros tienen un salario mensual. La clase de los empleados que trabajan por horas necesita unos atributos distintos que la clase de los otros empleados. En una base de datos orientada a objetos se deben crear las dos subclases de empleados. Aunque el SGBD nunca creara objetos de la clase Empleado, su presencia en el diseño clarifica el diseño lógico de la base de datos y ayuda a los programadores de aplicaciones permitiéndoles escribir sólo una vez los métodos que tienen en común las dos subclases (serán los métodos que se sitúan en la clase Empleado). En teoría, una base de datos orientada a objetos debe soportar dos tipos de herencia: la relación “es un” y la relación “extiende”. La relación “es un”, que también se conoce como generalización–especialización, crea una jerarquía donde las subclases son tipos específicos de las superclases.

 

Con la relación “extiende”, sin embargo, una clase expande su superclase en lugar de estrecharla en un tipo más específico. Por ejemplo, en la jerarquía de la clase Empleado, al igual que son necesarias clases para los empleados que realizan cada trabajo específico, hace falta guardar información adicional sobre los directores, que son empleados pero que también tienen unas características específicas. La base de datos incluirá una clase Director con un atributo para los empleados a los que dirige. En este sentido un director no es un empleado más específico sino un empleado con información adicional. Una de las cosas que es difícil de manejar en las bases de datos relacionales es la idea de las partes de un todo, como en una base de datos de fabricación, en la que hace falta saber que piezas y que componentes se utilizan para fabricar un determinado producto. Sin embargo, una base de datos orientada a objetos puede aprovechar la relación denominada “todo–parte” en la que los objetos de una clase se relacionan con objetos de otras clases que forman parte de él. En el caso de la base de datos de fabricación, la clase Producto se relacionara con las clases Pieza y Componente utilizando una relación “todo–parte”. Este tipo de relación es una relación de muchos a muchos con un significado especial. Un producto puede estar hecho de muchas piezas y muchos componentes. Además, una misma pieza o un mismo componente se puede utilizar para fabricar distintos productos. El identificar esta relación como “todo–parte” permite que el diseño sea más fácil de entender.

 

Integridad de las relaciones Para que las relaciones funcionen en una base de datos orientada a objetos pura, los identificadores de los objetos deben corresponderse en ambos extremos de la relación. Por ejemplo, si los aparejadores de una empresa de control de calidad se deben relacionar con las obras de construcción que supervisan, debe haber algún modo de garantizar que, cuando un identificador de un objeto Obra se incluye en un objeto Aparejador, el identificador de este mismo objeto Aparejador se debe incluir en el objeto Obra anterior. Este tipo de integridad de relaciones, que es de algún modo análogo a la integridad referencial en las bases de datos relacionales, se gestiona especificando relaciones inversas. La clase Aparejador tiene un atributo de tipo conjunto llamado supervisa. Del mismo modo, la clase Obra tiene un atributo llamado es supervisada. Para garantizar la integridad de esta relación, un SGBD orientado a objetos puro deberá permitir que el diseñador de la base de datos pueda especificar dónde debe aparecer el identificador del objeto inverso, como por ejemplo:

unidadii_sgbdoo imagen1

en la clase Obra.

 

Siempre que un usuario o un programa de aplicación inserta o elimina un identificador de objeto de la relación supervisa en un objeto Aparejador, el SGBD actualizara automáticamente la relación es supervisada en el objeto Obra relacionado. Cuando se hace una modificación en el objeto Obra, el SGBD lo propagara automáticamente al objeto Aparejador. Del mismo modo que en las bases de datos relacionales es el diseñador de la base de datos el que debe especificar las reglas de integridad referencial, en las bases de datos orientadas a objetos es también el diseñador el que debe especificar las relaciones inversas cuando crea el esquema de la base de datos.

 

El modelo estándar ODMG

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 última versión, ODMG 3.0, apareció en enero de 2000.

 

Los principales componentes de la arquitectura ODMG para un SGBD orientado a objetos son los siguientes:

  • Modelo de objetos.
  • Lenguaje de definición de objetos (ODL).
  • Lenguaje de consulta de objetos (OQL).
  • Conexión con los lenguajes C++, Smalltalk y Java.

 

 

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. 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 auto contenida 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, 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.

 

Objetos

Los tipos de objetos se descomponen en atómicos, colecciones y tipos estructurados. Los tipos colección, que se derivan de la interface Collection, son la propuesta del estándar para las clases contenedor. Los objetos colección identificados por el estándar son los siguientes:

 

Set : es un grupo desordenado de objetos del mismo tipo. No se permiten duplicados.

Bag : es un grupo desordenado de objetos del mismo tipo. Se permiten duplicados.

List : es un grupo ordenado de objetos del mismo tipo. Se permiten duplicados.

Array : es un grupo ordenado de objetos del mismo tipo que se pueden acceder por su posición. Su tamaño es dinámico y los elementos se pueden insertar y borrar de cualquier posición.

Dictionary : es como un índice. Está formado por claves ordenadas, cada una de ellas emparejada con un solo valor.

Los tipos estructurados son los siguientes:

 

Date : es una fecha del calendario (día, mes y año).

 

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.

 

Literales

Los tipos literales se descomponen en atómicos, colecciones, estructurados o nulos. Los literales no tienen identificadores y no pueden aparecer solos como objetos, sino que están embebidos en objetos y no pueden referenciarse de modo individual. Los literales atómicos son los siguientes:

 

boolean : un valor que es verdadero o falso.

short : un entero con signo, normalmente de 8 o 16 bits.

long : un entero con signo, normalmente de 32 o 64 bits.

unsigned short : un entero sin signo, normalmente de 8 o 16 bits.

unsigned long : un entero sin signo, normalmente de 32 o 64 bits.

float : un valor real en coma flotante de simple precisi´on.

double : un valor real en coma flotante de doble precisi´on.

octet : un almac´en de 8 bits.

char : un car´acter ASCII o UNICODE.

string : una cadena de caracteres.

enum : un tipo enumerado donde los valores se especifican explícitamente cuando se declara el tipo.

 

Los literales estructurados contienen un número fijo de elementos heterogéneos. Cada elemento es un par <nombre, valor> donde valor puede ser cualquier tipo literal. Los tipos estructurados son: date, time, timestamp, interval y struct. Y los tipos colecci´on son:

set<tipo>, bag<tipo>, list<tipo>, array<tipo> y dictionary<clave,valor>.

museo-fw

Tipos

Una de las características más importantes del paradigma orientado a objetos es la distinción entre la interface pública de una clase y sus elementos privados (encapsulación).

 

El estándar propuesto hace esta distinción hablando de la especificación externa de un tipo y de sus implementaciones. Una interface es una especificación del comportamiento abstracto de un tipo de objeto y contiene las signaturas de las operaciones. Aunque una interface puede tener propiedades (atributos y relaciones) como parte de su especificación, estas no pueden ser heredadas desde la interface. Además, una interface no es instánciale por lo que no se pueden crear objetos a partir de ella (es el equivalente de una clase abstracta en la mayoría de los lenguajes de programación).

Una clase es una especificación del comportamiento abstracto y del estado abstracto de un tipo de objeto. Las clases son instanciables, por lo que a partir de ellas se pueden crear instancias de objetos individuales (es el equivalente a una clase concreta en los lenguajes de programación). El estándar propuesto soporta la herencia simple y la herencia múltiple mediante las interfaces. Ya que las interfaces no son instanciables, se suelen utilizar para especificar operaciones abstractas que pueden ser heredadas por clases o por otras interfaces. A esto se le denomina herencia de comportamiento y se especifica mediante el símbolo “:”. La herencia de comportamiento requiere que el supertipo sea una interface, mientras que el subtipo puede ser una clase o una interface.  La herencia es una relación “es un”:

 

interface ArticuloVenta …;

interface Mueble : ArticuloVenta …;

class Silla : Mueble …;

class Mesa : Mueble …;

class Sof´a : Mueble …;

 

La interface o clase más baja de la jerarquía es el tipo más específico. Ya que hereda los comportamientos de todos los tipos que tiene por encima en la jerarquía, es la interface o clase más completa. En el ejemplo anterior, los tipos más específicos son Silla, Mesa y Sofá.

Uno de los beneficios prácticos de la herencia es que se puede hacer referencia a los subtipos como su supertipo. Por ejemplo, un programa de aplicación puede hacer referencia a sillas, mesas y sofás como muebles o incluso como artículos de venta. Esto hace que sea más sencillo tratar los subtipos como un grupo cuando sea necesario.

 

Los subtipos se pueden especializar como sea necesario añadiéndoles comportamientos. Los subtipos de un subtipo especializado heredan también los comportamientos añadidos. El modelo orientado a objetos utiliza la relación extiende (extends) para indicar la herencia de estado y de comportamiento. En este tipo de herencia tanto el subtipo como el supertipo deben ser clases. Las clases que extienden a otra clase ganan acceso a todos los estados y comportamientos del supertipo, incluyendo cualquier cosa que el supertipo haya adquirido a través de la herencia de otras interfaces.

Una clase puede extender, como máximo, a otra clase. Sin embargo, si se construye una jerarquía de extensiones, las clases de más abajo en la jerarquía heredan todo lo que sus supertipos heredan de las clases que tienen por encima. El modelo permite al diseñador que declare una extensión (extent) para cada tipo de objeto definido como una clase. La extensión de un tipo tiene un nombre e incluye todas las instancias de objetos persistentes creadas a partir de dicho tipo. Declarar una extensión denominada empleados para el tipo de objeto Empleado es similar a crear un objeto de tipo Set<Empleado> denominado empleados.

 

Una extensión se puede indexar para que el acceso a su contenido sea más rápido. Una clase con una extensión puede tener una o más claves (key). Una clave es un identificador único. Cuando una clave está formada por una sola propiedad, es una clave simple; si está formada por varias propiedades, es una clave compuesta. A diferencia del modelo relacional, las claves únicas no son un requisito. Una implementación de un tipo consta de dos partes: la representación y los métodos. La representación es una estructura de datos dependiente de un lenguaje de programación que contiene las propiedades del tipo. Las especificaciones de la implementación vienen de una conexión con un lenguaje (language binding). Esto quiere decir que la representación interna de un tipo será diferente dependiendo del lenguaje de programación que se utilice que un mismo tipo puede tener más de una representación.

 

Los detalles de las operaciones de un tipo se especifican mediante un conjunto de métodos. En la especificación externa de cada operación debe haber al menos un método. Sin embargo, un tipo puede incluir métodos que nunca se ven desde fuera del tipo. Estos métodos son los que realizan algunas funciones necesarias para otros métodos del tipo. Los métodos se escribirán en el mismo lenguaje de programación utilizado para expresar la representación del tipo. Si una base de datos soporta aplicaciones programadas en C++, Java y Smalltalk, entonces será necesario tener tres implementaciones para cada tipo, una para cada lenguaje, aunque cada programa de aplicaci´on utilizar´a s´olo la implementación que le corresponda.

 

Propiedades

El modelo de objetos ODMG define dos tipos de propiedades: atributos y relaciones. Un atributo se define del tipo de un objeto. Un atributo no es un objeto de “primera clase”, por lo tanto no tiene identificador, pero toma como valor un literal o el identificador de un objeto.

 

Las relaciones se definen entre tipos. El modelo actual sólo soporta relaciones binarias con cardinalidad 1:1, 1:n y n:m. Una relación no tiene nombre y tampoco es un objeto de “primera clase”, pero define caminos transversales en la interface de cada dirección. En el lado del muchos de la relación, los objetos pueden estar desordenados (set o bag) u ordenados (list). La integridad de las relaciones la mantiene automáticamente el SGBD y se genera una excepción cuando se intenta atravesar una relación en la que uno de los objetos participantes se ha borrado. El modelo aporta operaciones para formar (form) y eliminar

(drop) miembros de una relación.

 

Transacciones

El modelo estándar soporta el concepto de transacciones, que son unidades lógicas de trabajo que llevan a la base de datos de un estado consistente a otro estado consistente. El modelo asume una secuencia lineal de transacciones que se ejecutan de modo controlado. La concurrencia se basa en bloqueos estándar de lectura/escritura con un protocolo pesimista de control de concurrencia. Todos los accesos, creación, modificación y borrado de objetos persistentes se deben realizar dentro de una transacción. El modelo especifica operaciones para iniciar, terminar (commit) y abortar transacciones, así como la operación de checkpoint. Esta ´ultima operación hace permanentes los cambios realizados por la transacción en curso sin liberar ninguno de los bloqueos adquiridos.

 

Características de los sgbdoo

imagen2

 

  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. 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 super-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.

 

TIPOS DE SGBDOO

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
Creación de versiones.
BDOO

 

Está diseñada para simplificar la POO almacena objetos directamente en la base de datos empleando las mismas estructuras que leguajes de programación.
SGBOO

 

Es un sistema de objetos y un sistema de base de datos que almacena objetos permitiendo la concurrencia y recuperación. Pueden tratar directamente con los objetos sin hacer la traducción a tablas registros, para los programadores de aplicación (general o específica) los objetos se conservan en su forma y tamaño pueden compartirse con múltiples usuarios.

Niveles de abstracción

  • Interno.- Como se van a guardar los objetos (disco duro)
  • Conceptual.- Como guardar la estructura
  • Externo.- Lo que vamos a mostrar al usuario (interfaz)

 

Consideraremos el problema de almacenar un coche en el garaje en un sistema de objetos, el coche es un objeto, el garaje es un objeto y hay una operación simple que es almacena el coche en el garaje. En el sistema relacional todos los datos se traducen en tablas, entonces el coche debe de ser desarmado, las llantas se colocan en un lugar, los birlos en otro lugar, por la mañana antes de salir hay que componer el coche antes de conducir.

  • Aplicaciones de la BDOO
  • Diseño asistido por computadora CAD
  • Fabricación asistida por computadora CAM
  • Ingeniería de software asistido por computadora CASE
  • Sistemas de gestión de red
  • Sistemas de información de oficina y sistemas multimedia OIS
  • Sistema autoedición digital
  • Sistemas de información geográfica GIS
  • Sistemas Web interactivos dinámicos.

 

sinfronteras-fw

 

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 orientados 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.

 

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 un objeto 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).

 

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 baseclase padresuperclaseclase 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.

 

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.

 

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 cache.
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 delas 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 haya 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 sistemas, 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.

 

http://www3.uji.es/~mmarques/e16/teoria/cap2.pdf

http://acrediteme.blogspot.mx/2013/12/unidad-2-sistemas-de-base-de-datos.html

Descarga el archivo completo: unidadii_sgbdoo

Web Hosting

 

promouno-fw

Dejar un Comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *