INSTITUTO UNIVERSITARIO DE TECNOLOGÍA DE ADMINISTRACIÓN

INDUSTRIAL ALTOS MIRANDINOS

CARRERA: INFORMÁTICA
SECCIÓN: 203B1
UNIDAD CURRICULAR: ANALISIS DE SISTEMAS
UNIVERSITARIA PROFESOR: DAMARYS LINARES

MODELO DE BASES DE DATOS

ORIENTADOS A OBJETOS

Estudiante:

Franco González
C.I.N°V.30.051.776

Los Teques, 15 Julio del 2021

 INTRODUCCIÓN

La construcción de un sistema software, con independencia de su tamaño,

de sus características funcionales y de la tecnología elegida, consta de una serie
de fases que abarcan desde su concepción hasta su retirada, definiendo un
espacio temporal que recibe el nombre de ciclo de vida del software. Existen
diferentes modelos de ciclo de vida, cada uno con sus propias peculiaridades,
adaptándose unos mejor que otros a los distintos paradigmas o estilos de
programación. Pero, lo que sí se puede afirmar es que en ninguno de estos
modelos de desarrollo se comienza con un proyecto software por la fase de
implementación. Comenzar un proyecto software por la fase de implementación,
esto es decir, colocarse inmediatamente delante del ordenador y comenzar a
generar código fuente, es desgraciadamente una forma de trabajo bastante
extendida, que toma sus tintes más preocupantes cuando sale del entorno del
programador ocasional o aficionado, para convertirse en la forma de trabajo de la
inmensa mayoría de las empresas de construcción de software dentro y fuera de
nuestras fronteras. Por lo tanto, puede parecer utópico y dar la sensación de
predicar en el desierto, el dedicar un artículo al análisis y el diseño en la
orientación a objeto, cuando prácticamente nadie se molesta en seguir unos
principios metodológicos básicos en sus desarrollos y, además, la orientación a
objeto en nuestro país no acaba de convertirse en una alternativa completamente
aceptada. No obstante, desde nuestra modesta posición vamos a intentar aportar
nuestro granito de arena en favor de lo que sería una forma más correcta de
realizar la construcción de una aplicación software desde el prisma de la
orientación a objetos.

Las bases de datos relacionales,( es un tipo de base de datos

que almacena y proporciona acceso a puntos de datos relacionados entre sí) se
inició en el año 2000 eran las más utilizadas en la mayoría de los ámbitos de
aplicación. La estructura de datos básica que ofrece, la tabla relacional, es
apropiada para muchas aplicaciones habituales. Sin embargo, existen casos de
uso en los que presenta serios inconvenientes prácticos, generalmente si se
requiere gestionar datos muy complejos o no convencionales (imágenes,
documentos...), para los que las estructuras relacionales resultan muy complejas e
ineficientes. Algunos ejemplos de gran importancia práctica son las bases de
datos multimedia, las bases de datos científicos y los sistemas de apoyo al diseño
industrial (cad/cam)..

Las bases de datos orientadas a objetos intentan dar respuesta a estos

problemas, incorporando las siguientes características: Adoptan como modelo de
datos el de los lenguajes orientados a objetos, permitiendo así el uso de
estructuras de datos tan complejas como sea necesario y eliminando en gran
medida las barreras entre el desarrollo de aplicaciones y la gestión de datos.
Permiten la extensibilidad con nuevos tipos de datos complejos, permitiendo
incorporar operaciones arbitrarias sobre ellos. Estas características han motivado
el desarrollo de numerosos sistemas orientados a objetos. Juntamente al avance
vertiginoso de desarrollo de WebApps que requieren estructuras de datos muy
flexibles.

Objetivo propuestos por las Bases de Datos Orientadas a Objetos

Proporcionar un modelo de datos mucho más rico y extensible, y así
complementar (aunque no sustituir) a las bases de datos relacionales. Lograr una
equivalencia al de los lenguajes de programación orientados a objetos, como C++
o Java. Esto tiene la gran ventaja de que, al compartir el modelo de datos, se
pueden integrar las BDOO con el software usado para desarrollar aplicaciones, de
manera directa y casi transparente. (en las BDR es necesario usar dos lenguajes:
a) uno de programación para la aplicación, y b) sql para el acceso a la base de
datos, lo que implica realizar costosas conversiones. Disponer de nuevas
características para el modelado de datos complejos (BDOR. Las últimas
versiones del estándar sql, a partir de sql99, también incluyen muchas de estas
funcionalidades. Entre ellas se incluyen la posibilidad de almacenar en tablas
relacionales grandes objetos binarios (denominados «blobs», por Binary Large
OBjects), como imágenes, sonido o video; las herramientas de gestión de
documentos (índices y operadores específicos para buscar texto, soporte de xml);
y otras extensiones para soportar datos.

Fases de un desarrollo orientado a objetos Nada más lejos de la intención de este

artículo que realizar la descripción de ningún modelo de ciclo de vida del software,
ya que para este fin el lector puede recurrir a cualquiera de los textos clásicos
sobre ingeniería del software, por ejemplo [1] y [2], donde encontrará una
información más amplia y precisa. Pero, dado que se ha comenzado el artículo
criticando la construcción de las aplicaciones que empiezan directamente por la
codificación, se va a dar un marco muy general de lo que sería un desarrollo
software, marco que en su generalidad es perfectamente válido para cualquier tipo
de desarrollo, independientemente que sea orientado a objeto o no. El marco de
desarrollo de una aplicación software estaría formado por las tres fases
tradicionales: análisis, diseño e implementación. El análisis es la fase cuyo
objetivo es estudiar y comprender el dominio del problema, es decir, el análisis se
centra en responder al interrogante ¿QUÉ HACER? El diseño, por su parte, dirige
sus esfuerzos en desarrollar la solución a los requisitos planteados en el análisis,
esto es, el diseño se haya centrado en el espacio de la solución, intentando dar
respuesta a la cuestión ¿CÓMO HACERLO? Por último, la fase de
implementación sería la encarga de la traducción del diseño de la aplicación al
lenguaje de programación elegido, adaptando por tanto la solución a un entorno
concreto.

Las Bases de Datos Orientadas a Objetos, adoptan como modelo de datos el de

los lenguajes orientados a objetos, permitiendo así el uso de estructuras de datos
tan complejas como sea necesario, y eliminando en gran medida las barreras
entre el desarrollo de aplicaciones y la gestión de datos.
Permiten la extensibilidad con nuevos tipos de datos complejos, permitiendo
incorporar operaciones arbitrarias sobre ellos.

Entre las BDOO y las BD Relacionales, podemos tener, las siguientes diferencias:

EJEMPLO DE DISEÑO DE UNA BDOO

define data type Teléfonos: set(integer);

define data type Fecha: tuple(año:integer, mes:integer, dia:integer),

define object type Persona extent Personas

type
tuple(ci: string,
nombre: tuple ( nombre _per: string,
apellido_past:string
apellido_mat:string)
direccion: tuple (numero:integer, calle:string, ciudad:string)
fechanac:Fecha
sexo: char)
operations
edad:integer;

BDOO :

Los modelos de datos equivalentes a los lenguajes de programación Orientados a

Objetos.

Se pueden integrar las BDOO con el software usado para desarrollar aplicaciones
directa y transparente.

BD Relacionales:

El modelo de Datos no equivalentes a los lenguajes de programación Orientadas a

Objetos.
Se usa un lenguaje de programación para la aplicación y SQL para el acceso de la
base de datos.

Niveles de soporte de la tecnología OO en BD A pequeña escala se encuentran

las librerías que permiten el almacenamiento persistente de objetos. Estas están
disponibles para cualquier lenguaje de programación orientado a objetos. Después
están las bases de datos objeto-relacionales, para aplicaciones que requieren usar
algunos tipos de datos complejos en un entorno esencialmente relacional, y que
se basan en extensiones orientadas a objetos de sql. Finalmente, las bases de
datos orientadas a objetos puras proporcionan una gestión de bases de datos
orientadas a objetos a todos los niveles, desde la definición de datos al lenguaje
de consulta.

8 8 Persistencia de objetos

Persistencia. es qué objetos deberán permanecer en la base de datos una vez que
el programa haya terminado, y cuáles no. Los objetos transitorios desaparecen
una vez que el programa que los creó termina de ejecutarse, mientras que los
objetos persistentes permanecen almacenados en la base de datos. Para hacer un
objeto persistente hay tres alternativas. La primera es marcarlo
explícitamente como persistente. Hacerlo alcanzable a partir de otro objeto ya
marcado como persistente. Es añadiéndolos a una colección persistente de su
clase. 8 8 8

8 Persistencia de objetos.

Marcado explícitamente. En el ejemplo (en Java se utiliza db4o) se crea un objeto

de tipo Empleado, que a se marca como persistente usando el método store. El
objeto contenedor encapsula el almacenamiento de objetos. A partir de este
momento, todos los cambios que se produzcan en este objeto se guardarán
automáticamente. Al marcar un objeto como persistente existe la posibilidad de
asignarle un nombre único dentro de la base de datos, a través del cual el
SGBDOO permite a los usuarios y a los programas acceder a él. Los objetos con
nombre único suelen ser poco

Persistencia de objetos. Alcanzable a partir de otro objeto

Se dice que un objeto A es alcanzable desde otro B, si hay alguna cadena de

referencias que llevan desde el objeto B hasta el objeto A. Esta cadena de
referencias puede ser muy larga y pasar por muchos objetos. De esta manera,
cuando se hace un objeto persistente, todos los objetos alcanzables a partir de él
se hacen implícitamente persistentes.

Características de los SGBDOO

El conjunto de reglas equivalente para los sistemas orientados a objetos se

conoce como el Manifiesto de las bdoo, y fue definido en 1992. Consta de las 13
reglas obligatorias para considerar que un SGBD es OO y de cinco opciones de
implementación que no son obligatorias. Herencia múltiple Verificación e inferencia
de tipos Distribución de los datos Transacciones Versionado de objetos Ninguna
base de datos comercial cumple todas las reglas del Manifiesto, por lo que puede
decirse que estas reglas describen un sistema idealizado no disponible en la
realidad. Sin embargo, en la práctica se trata de una lista muy útil para analizar los
SGBDOO y determinar si se ajusta.

Ventajas de las SGBDOO

Mayor capacidad de modelado. El modelado de datos orientado a objetos

permite modelar el ‘mundo real’ de una manera mucho más fiel. Esto se debe a: a)
o un objeto permite encapsular tanto un estado como un comportamiento, b) o un
objeto puede almacenar todas las relaciones que tenga con otros objetos; c) o los
objetos pueden agruparse para formar objetos complejos (herencia).
Ampliabilidad. Esto se debe a: a) o Se pueden construir nuevos tipos de datos a
partir de los ya existentes; b) o Agrupación de propiedades comunes de diversas
clases e incluirlas en una superclase, lo que reduce la redundancia.; c) o
Reusabilidad de clases, lo que repercute en una mayor facilidad de mantenimiento
y un menor tiempo de desarrollo. Lenguaje de consulta más expresivo. El acceso
navegacional desde un objeto al siguiente es la forma más común de acceso a
datos en un SGBDOO. Mientras que SQL utiliza el acceso asociativo. El acceso
navegacional es más adecuado para gestionar operaciones como los despieces,
consultas recursivas, etc. Adecuación a las aplicaciones avanzadas de base de
datos. Hay muchas áreas en las que los SGBD tradicionales no han tenido
excesivo éxito como el CAD, CASE, OIS, sistemas multimedia, etc. en los que las
capacidades de modelado de los SGBDOO han hecho que esos sistemas sí
resulten efectivos para este tipo de aplicaciones. Mayores prestaciones. Los
SGBDOO proporcionan mejoras significativas de rendimiento con respecto a los
SGBD relacionales. Aunque hay autores que han argumentado que los bancos de
prueba usados están dirigidos a aplicaciones de ingeniería donde los SGBDOO
son más adecuados. También está demostrado que los SGBDR tienen un
rendimiento mejor que los SGBDOO en las aplicaciones tradicionales de bases de
datos como el procesamiento de transacciones en línea (OLTP). 15
Inconvenientes de las SGB

Inconvenientes de las SGBDOO

Carencia de un modelo de datos universal. No hay ningún modelo de datos

que esté universalmente aceptado para los SGBDOO y la mayoría de los modelos
carecen una base teórica. Carencia de experiencia. Todavía no se dispone del
nivel de experiencia del que se dispone para los sistemas tradicionales. Carencia
de estándares. Existe una carencia de estándares general para los SGBDOO.
Competencia. Con respecto a los SGBDR y los SGBDOR. Estos productos tienen
una experiencia de uso considerable. SQL es un estándar aprobado y ODBC es
un estándar de facto. Además, el modelo relacional tiene una sólida base teórica y
los productos relacionales disponen de muchas herramientas de soporte que
sirven tanto para desarrolladores como para usuarios finales. La optimización de
consultas compromete la encapsulacion. La optimización de consultas requiere
una compresión de la implementación de los objetos, para poder acceder a la
base de datos de manera eficiente. Sin embargo, esto compromete el concepto de
encapsulación. El modelo de objetos aún no tiene una teoría matemática
coherente que le sirva de base. 16 Objetos complejos Una de las motivaciones
para

ODMG: el estándar de facto para modelos de objetos

ODMG es un grupo de representantes de la industria de bases de datos el

cual fue concebido en el verano de 1991 con el objetivo de definir estándares para
los SGBDOO. Uno de sus estándares, el cual lleva el mismo nombre del grupo
(ODMG), es el del modelo para la semántica de los objetos de una base de datos.
El modelo de objetos ODMG es un super conjunto del modelo de objetos de OMG,
que permite portar tanto los diseños como las implementaciones entre diversos
sistemas compatibles.

ODMG: el estándar de facto para modelos de objetos

Elementos que componen un objeto Identidad de los objetos Constructores

de tipos y objetos Referencia entre objetos Estado de los objetos Comportamiento
de los objetos Clasificación e instanciación de objetos 23 ODMG: el estándar de
facto para modelos de objetos Objetos En las BDOO todos los elementos que se
manejan son objetos. Cada objeto se corresponde con una entidad de la realidad,
y define sus propiedades y comportamiento. Definición: un objeto es una
representación abstracta de una entidad del mundo real que tiene una identidad
única dentro de la base de datos, unas propiedades incorporadas en sí mismo, y
un comportamiento que le proporciona la capacidad de interaccionar con otros
objetos y consigo mismo. Los objetos que comparten propiedades y
comportamiento forman clases. 24 Los objetos, al igual que las filas de las bases
de datos relacionales, expresan las propiedades de los elementos de la realidad.
Sin embargo, los objetos, al contrario que las tuplas, tienen identidad y son
elementos activos, de tal forma que poseen un comportamiento y pueden
interaccionar entre sí. ODMG: el estándar de facto para modelos de objetos
Identidad (oid) La identidad de cada objeto se representa por medio de un oid
(Object Identifier), el cual es único para ese objeto. Es asignado por el sistema en
el momento en que el objeto es creado y no puede ser alterado bajo ninguna
circunstancia. No es visible para el usuario externo, sino que el sistema lo utiliza
internamente para identificar al objeto, y para referenciarlo desde otros objetos. La
diferencia entre un oid y una clave primaria está en que la clave primaria se basa
en los valores dados por los usuarios para ciertos atributos, los cuales pueden ser
alterados en cualquier momento. Sin embargo, el oid es asignado por el sistema,
debe ser independiente del valor de cualquier atributo, y no puede ser alterado.
Solo puede desaparecer cuando su objeto lo haga, y en ese caso nunca puede
volver a ser utilizado. Tampoco puede referirse a ninguna dirección de memoria.
Así se consigue que la manera en que se representan los objetos y sus relaciones
sea independiente del formato de almacenamiento físico de los datos. 25 Identidad
(oid) Dos objetos con el mismo oid se consideran idénticos: se trata a todos los
efectos del mismo objeto. Es importante remarcar que dos objetos que no sean
idénticos pueden ser iguales si sus valores también lo son. Se trata de dos
conceptos de igualdad diferentes, que tanto los lenguajes como las bases de
datos orientadas a objetos diferencian claramente. 26 Por ejemplo, en el lenguaje
Java se usa el operador == para comprobar si dos objetos son idénticos, y el
método equals() para comprobar si sus valores son iguales. ODMG: el estándar de
facto para modelos de objetos Propiedades de los objetos Cada objeto de una
base de datos tiene asignado un valor que expresa sus propiedades y que puede
ser actualizado a lo largo del tiempo. El valor de un objeto se ajusta a una
estructura de datos que puede ser tan compleja como sea necesario. Esta
estructura de datos se construye a partir de unos tipos de datos básicos por medio
de unos constructores de tipos de datos y de tipos de objetos, que se pueden
combinar arbitrariamente. Entre los tipos de datos básicos que proporcione un
SGBDOO también pueden aparecer tipos de datos multimedia y texto. En este
caso, el sistema también debe proveer las operaciones necesarias para manipular
los valores multimedia y textuales. Los SGBDOO más avanzados permiten al
usuario definir sus propios tipos de datos básicos con sus propias operaciones.
Esto hace al sistema muy flexible y capaz de soportar los datos de cualquier
aplicación. Constructores de objetos Referencias entre objetos Estado de los
objetos 27 ODMG: el estándar de facto para modelos de objetos Objetos Los tipos
de objetos se descomponen en e atómicos, colecciones y tipos estructurados. 28
Constructores de átomos (elementos de los dominios básicos: enteros, reales,
cadenas, etc.); Constructores de colecciones, que suelen ser tuplas ([…]),
conjuntos ({…}) y listas (//…//, set, bag, Array, Dictionary). Tipos estructurados
(date, time, timestamp, interval, etc. Las tuplas tienen varios componentes
llamados atributos con un nombre y un tipo. Los conjuntos son un número de 0 o
más elementos del mismo tipo y que no se repiten. Las listas son como los
conjuntos pero conservando el orden de inserción. Los set son un grupo
desordenado de objetos del mismo tipo. No se permiten duplicados. Los bag son
un grupo desordenado 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 no es dinámico y los elementos se pueden insertar y borrar
de cualquier posición. Dictionary es como un incidec. Está formado por claves
ordenadas, cada una de ellas emparejadas con un solo valor. Los objetos se crean
utilizando el método new(). Los BDOO, como los lenguajes de POO, pueden
proporcionar otros tipos.

Diseño físico de bases de datos orientadas a objetos

Al igual que en las BDR, el modelo lógico de datos de las BDOO es

independiente de la localización física de los datos. Los datos también se
almacenan en ficheros emplazados en diferentes dispositivos físicos que el
administrador de la base de datos tiene que gestionar. Muchos de los conceptos
de diseño físico de BDR se pueden aplicar para las BDOO. Sin embargo, hay
ciertos cambios en la forma en que s e realizan los agrupamientos y los índices de
acceso a los datos, que deben ser estudiados.
 CONCLUSIONES

Se ha intentado transmitir en este artículo la idea de que un desarrollo de software

conlleva más actividades que las de implementación, plasmando someramente las principales
actividades que se llevan a cabo en el ADOO y centrándonos especialmente en la tarea de
identificación de los objetos que capturan la semántica de la aplicación, y en la necesidad de
plasmarlos en una serie de modelos que representen el sistema. En cuanto al tema de modelado,
se ha incidido de nuevo en el uso de UML 1, pero haciendo especial hincapié en los diferentes
tipos de diagramas que este lenguaje de modelado presenta. Somos conscientes de que la
presentación de dichos diagramas ha sido demasiado superficial, pero el estudio de cada uno de
ellos por separado es un tema demasiado extenso. No obstante, y dado la especial repercusión
que tiene sobre la implementación.

BIBLIOGRAFÍA

A. De Miguel, M. Piattini. Fundamentos y Modelos de las Bases de Datos.

2ª edición. Madrid. Editorial Ra-Ma/México y Colombia, AlfaOmega Grupo Editor.
1999. ISBN 978-84-78-97361-3. Maria Jose Aramburu Cabo. Bases de Datos
Avanzada. Universitat Jaumi. ISBN: 978-84-695-6769-2. Atkinson, M. et al. (1989):
The Object-Oriented Database System Manifesto, Proceedings of 1st International
Conference on Deductive and Object-Oriented Databases. Cattell, R. et al. (2000):
The Object Data Standard: odmg 3.0, Morgan Kaufmann. Harrington, J. (2000):
Object Oriented Database Design Clearly Explained, Morgan Kaufmann.
Silberschatz, A., Korth, H., Sudarshan, S. (2002): Fundamentos de Bases de
Datos, (4.a edición), McGraw Hill.