UNIVERSIDAD NORORIENTAL

GRAN MARISCAL DE AYACUCHO

FACULTAD DE INGENIERIA-ESCUELA DE INGENIERIA EN INFORMATICA

NUCLEO CIUDAD BOLIVAR-ESTADO BOLIVAR

Base de datos orientada a objetos

Tutor Académico: Realizador por:

Manuel Carrasquero Palacios, Celeni

C. l 26.829.811

Ciudad Bolívar, Abril Del 2023

Reseña historia de la base de datos orientada a objeto

A inicios de la década de los años 60 se gesta el origen de este tipo de bases de datos. Ocurre en
Noruega, donde el doctor Nygaard, especialista en la elaboración de sistemas informáticos que llevaban
a cabo simulaciones de sistemas de naturaleza física, puso a punto esta nueva tendencia. Acostumbrado
a buscar la representación informática del rendimiento de elementos físicos como el motor de un coche,
Nygaard tenía ciertas necesidades que hasta ese momento nadie podía satisfacer. En su época, todavía
los sesenta, había ciertos obstáculos que impedían que su trabajo pudiera llegar a buen puerto. Se
encontraba con que el software del momento era excesivamente complicado y debía recurrir a
modificaciones en cada una de sus operaciones. El proceso de trabajo superaba los límites de la
comodidad, dado que por cada iniciativa que llevaba a cabo tenía que contemplar varias alteraciones y
posibilidades que cubrían las alternativas a sus planteamientos. Todo ello hacía que el trabajo fuera
demasiado absorbente y que se saliera de los límites de lo tolerable.

Esta situación hizo que el doctor Nygaard y su equipo planteasen alternativas. Así es como trabajaron en
la elaboración de un software que se diseñase de forma paralela al objeto físico en cuestión. Esto
suponía cambiar la forma de trabajar, pero con el objetivo de alcanzar un resultado mucho más
adecuado y beneficioso. El equipo del doctor planteó un requisito clave: que el programa fuera un reflejo
del objeto. Si el objeto físico en cuestión estaba formado por 50 componentes principales, el software
también debería tener 50 módulos. Esto garantizaría que por cada pieza del objeto habría una
contraposición en el software, todo ello visible y analizable. Y si el objeto en cuestión funcionaba bien
gracias a la comunicación de sus 50 piezas, el software también lo haría a través de la comunicación de
los 50 módulos y de sus componentes.

¿Qué ganó Nygaard? Se encontró con que su solución le resolvía todos los problemas. Disponía de un
mantenimiento absolutamente dominado, sin sorpresas, pero al mismo tiempo también veía que ahora
sus programas se podían dividir de forma lógica. De esta forma, con los posteriores análisis y pruebas el
doctor podría cambiar las piezas de forma independiente y cómoda, así como hacerlo con facilidad. Así
es como comenzó a realizar pruebas más fiables, específicas y de resultados precisos. Y entonces se
descubrió su potencialUno de los principales problemas a los que se enfrentaba Nygaard en su época se
encontraba en que debía realizar procesos de trabajo largos para una tarea posterior que no simbolizaba
tanta dificultad. No era tirar horas de trabajo a la basura, pero sí sentía que su tiempo se estaba
desperdiciando dentro del contexto. Por eso planteó soluciones y descubrió que finalmente la
orientación a objetos con la que había trabajado le resolvía este aspecto. El motivo se encontró en que
pudo introducir la reusabilidad en la creación del software. A partir de este momento cada programa no
representaba un inicio y final para el software, sino que en el proceso de creación muchos elementos
podían recuperarse y mantenerse en activo para futuras creaciones.

Pero con este descubrimiento Nygaard necesitaba un lenguaje que le sirviera de apoyo. Así fue como
nació Simula-67, lenguaje que hoy día aún se usa y que está considerado como uno de los inventos más
importantes en el mundo de la informática aunque no sea algo conocido en términos populares.

Con el paso del tiempo la industria continuó el trabajo en las bases de datos orientada a objetos. Una
década después el equipo de Alan Kay y Xerox tomó de referencia el trabajo de Simula-67 para crear otro
lenguaje similar: Smalltalk. En los años 80 este lenguaje fue utilizado en combinación con algunas de las
ideas que habían sido más características de Simula-67 para dar forma a otro lenguaje que tiene gran
importancia hoy día: C++, que se ocupó de que este tipo de trabajo alcanzara sus máximos niveles de
rendimiento.

Descripción de los modelos

Los modelos de bases de datos tradicionales presentan deficiencias en cuento a aplicaciones más
complejas o sofisticadas. Además son difíciles de utilizar cuando las aplicaciones que acceden a ellas
están escritas en un lenguaje de programación orientado a objetos.

La orientación a objetos ofrece flexibilidad, no está limitada por los tipos de datos y los lenguajes de
consulta de los sistemas de bases de datos tradicionales. La característica clave es la potencia que
proporcionan al diseñador al permitirle especificar tanto la estructura de objetos complejos, como las
operaciones que se pueden aplicar sobre dichos objetos. Las BDOO se han diseñado para que se puedan
integrar directamente con aplicaciones desarrolladas con lenguajes orientados a objetos. También están
diseñadas para simplificar la POO. Almacenan los objetos en la BD con las mismas estructuras y
relaciones que los lenguajes de POO.

Una SGBDOO es una SGBD que almacena objetos incorporando así todas las ventajas de la OO. Pueden
tratar directamente con objetos, no teniendo que hacer la traducción a tablas o registros. Sus objetos se
conservan, pueden ser gestionados aunque su tamaño sea grande, pueden ser compartidos entre
múltiples usuarios y mantienen su integridad como sus relaciones. ODMG (Object Database Mangement
Group) es el grupo de fabricantes de SGBDOO 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

Persistencia de datos

La persistencia de datos es la existencia residual de datos digitales que permanecen incluso después de
que se ha intentado eliminarlos o borrarlos. La persistencia de datos provoca que los datos queden
intactos incluso después de una operación de eliminación de archivos, del reformateo de medios de
almacenamiento que no eliminan los datos previamente escritos, o a través de propiedades físicas de los
medios de almacenamiento que permiten recuperar los datos, con el riesgo de la divulgación inadvertida
de información sensible.

La persistencia de datos se refiere a los datos residuales que quedan de un archivo luego de que se han
hecho intentos para eliminarlo o borrarlo. Estos residuos pueden ser causados por el proceso de
eliminación llevado por el sistema operativo que deja los datos intactos, por el formateo de medios de
almacenamiento que no elimina los datos previamente existentes en el medios, o debido a las
características físicas del medio de almacenamiento que permiten recuperar datos previamente escritos.

La persistencia de datos puede permitir la recuperación de la información y la puede dejar expuesta si no

se hace un correcto manejo del dispositivo y se libera en un entorno no controlado, por ejemplo si se
pierde, se arroja a la basura o se deja en manos de terceros. Muchos sistemas operativos, gestores de
archivos y otro software proporcionan métodos de borrado en los que un archivo no se elimina
inmediatamente cuando el usuario solicita esa acción. En su lugar, el archivo se mueve a un área de
almacenamiento temporal, denominado usualmente “Papelera de reciclaje”, lo que facilita al usuario
deshacer un error.

Del mismo modo, muchos productos de software crean automáticamente copias de seguridad de los
archivos que se están editando, para permitir al usuario restaurar la versión original o recuperarse de un
posible fallo, característica denominada usualmente “Autosave” (“Autoguardado”).

Incluso cuando no se proporciona un recurso de retención temporal de archivos borrados o cuando el

usuario no lo utiliza, los sistemas operativos no eliminan realmente el contenido de un archivo cuando se
elimina, a menos que se utilicen conscientemente herramientas de borrado seguro. En su lugar,
simplemente eliminan la entrada del archivo del directorio del sistema de archivos porque es más rápido
y requiere menos trabajo, y el contenido del archivo permanece en el medio de almacenamiento hasta
que el sistema operativo reutilice el espacio para guardar nuevos datos.

En algunos sistemas, por diversos motivos también se dejan atrás suficientes metadatos del sistema de
archivos como para permitir una fácil recuperación de archivos mediante utilidades de software. Incluso
cuando la recuperación es imposible, los datos, hasta que se han sobrescrito, pueden ser leídos por un
software que lea los sectores del disco directamente. La informática forense emplea a menudo tal
software.

Del mismo modo, reformatear o reparticionar un sistema es poco probable que sobrescriba todas las
áreas del disco, aunque parezca que el disco está vacío. Lo mismo ocurre en caso de efectuar una copia
imagen de otro soporte de datos, aunque el medio aparezca vacío excepto los archivos presentes en la
imagen, muchos datos no habrán sido sobrescritos.

Además, incluso cuando el medio de almacenamiento se sobrescribe, sus propiedades físicas pueden
permitir la recuperación del contenido anterior. Sin embargo, en la mayoría de los casos esta
recuperación no es posible simplemente leyendo el dispositivo de almacenamiento con herramientas
convencionales, sino que se requiere el uso de técnicas de laboratorio, tales como desmontar el
dispositivo y acceder/leer directamente sus componentes.

Se han desarrollado diversas técnicas para contrarrestar la persistencia de datos y minimizar los riesgos
de exposición de la información, tales como sobrescribir, desmagnetizar, cifrar y destruir los medios.

Sobrescritura: Un método comúnmente utilizado para contrarrestar la persistencia de datos es

sobrescribir los medios de almacenamiento con nuevos datos. Debido a que este método puede
implementarse a menudo exclusivamente en base a software, y puede ser capaz de seleccionar
selectivamente sólo una parte del medio, es una opción popular y de bajo costo para algunas
aplicaciones. La sobrescritura es generalmente un método aceptable de borrar, siempre y cuando el
soporte sea escribible y no esté dañado. La técnica de sobrescritura más simple escribe los mismos datos
en todas partes, a menudo sólo un patrón de ceros o unos. Como mínimo, esto evitará que los datos
sean recuperados simplemente leyendo de nuevo los medios usando funciones estándar del sistema.
Para contrarrestar técnicas de recuperación de datos más avanzadas, se han desarrollado patrones de
sobrescritura específicos aleatorios o con múltiples pasadas, destinados a erradicar cualquier traza de
firmas.

Desmagnetización: La desmagnetización es la eliminación o reducción del campo magnético de un disco

o unidad, utilizando un dispositivo denominado desmagnetizador, diseñado para el medio que se va a
borrar. Aplicada a medios magnéticos, la desmagnetización puede purgar todo un medio de forma rápida
y eficaz. La desmagnetización a menudo hace que los discos duros no funcionen, ya que borra el formato
de bajo nivel que sólo se realiza en la fábrica durante la fabricación. En algunos casos, es posible devolver
la unidad a un estado funcional haciéndola reparar en el fabricante. Sin embargo, algunos
desmagnetizadores utilizan un pulso magnético tan fuerte que incluso el motor que gira los platos puede
ser destruido en el proceso de desmagnetización, y el arreglo puede no ser rentable.

Encriptación: El cifrado de datos al almacenarlos puede mitigar las preocupaciones sobre la persistencia
de datos. Si la clave de cifrado es fuerte y está cuidadosamente controlada, el cifrado puede conseguir
de manera efectiva que cualquier información almacenada en el medio sea irrecuperable. Si la clave está
almacenada en el medio, puede resultar más fácil o más rápido sobrescribir sólo la clave, frente a
sobrescribir todo el disco. El cifrado se puede hacer archivo por archivo, o en el disco entero.

Destrucción física: La destrucción física de los medios de almacenamiento es la forma más segura de
contrarrestar la persistencia de datos. Sin embargo, el proceso es generalmente largo, engorroso y
puede requerir métodos extremadamente complejos, ya que incluso un fragmento pequeño del medio
puede contener grandes cantidades de datos. Las técnicas específicas de destrucción incluyen deshacer
físicamente el medio (por ejemplo, por trituración), alterar químicamente el medio (por ejemplo,
mediante incineración o exposición a productos químicos cáusticos o corrosivos) o exponer el medio a
campos electromagnéticos que exceden en gran medida las especificaciones (por ejemplo, corriente
eléctrica de alto voltaje o radiación de microondas de alta amplitud), entre otros.

Existen diversas normas industriales y militares para la eliminación segura de datos, a fin de evitar la
persistencia de datos, cuyo cumplimiento se puede requerir en algunos entornos de alta seguridad y
jurisdicciones militares.

Hay tres niveles comúnmente reconocidos en la eliminación de datos persistentes:

Compensación (Clearing): Consiste en remover del dispositivo de almacenamiento los datos sensibles, de
una forma que resulte imposible recuperarlos con las herramientas ofrecidas por el sistema operativo o
con un software de recuperación de datos. Sin embargo los datos son recuperables con técnicas
realizadas en laboratorios especializados.

Purga (Purging): También conocida como higienización (Sanitizing), la purga consiste en remover los
datos sensibles da tal forma que no sean recuperables bajo ninguna técnica conocida. La purga se hace
de una forma proporcional a la importancia de los datos, normalmente este proceso se hace antes de
desechar a la basura un dispositivo de almacenamiento o cuando se traslada a otra computadora. Para
lograr la purga se usan técnicas como la sobrescritura, que consiste en sobrescribir varias veces el
espacio del que se quieren remover los datos persistentes.

Destrucción (Destruction): Consiste en la destrucción física del medio de almacenamiento, utilizando

técnicas de destrucción como la trituración, la incineración y la aplicación de cargas eléctricas por encima
de las que resiste el medio. Este es el método más drástico y el más seguro si se hace correctamente, ya
que de lo contrario puede dejar datos recuperables mediante métodos de laboratorio.

MANIFIESTO MALCOLM ATKINSON

En 1989 se hizo el Manifiesto de los sistemas de base de datos orientados a objetos el cual propuso trece
características obligatorias para un SGBDOO y cuatro opcionales. Las trece características obligatorias
estaban basadas en dos criterios: debía tratarse de un sistema orientado a objetos y un SGBD.

Características obligatorias de orientación a objetos:

1) Deben soportarse objetos complejos.

2) Deben soportarse mecanismos de identidad de los objetos.

3) Debe soportarse la encapsulación.

4) Deben soportarse los tipos o clases.

 5) Los tipos o clases deben ser capaces de heredar de sus ancestros.

6) Debe soportarse el enlace dinámico.

7) El DML debe ser computacionalmente complejo.

8) El conjunto de todos los tipos de datos debe ser ampliable.

Características obligatorias de SGBD:

9) Debe proporcionarse persistencia a los datos.

10) El SGBD debe ser capaz de gestionar bases de datos de muy gran tamaño.

11) El SGBD debe soportar a usuarios concurrentes.

12) El SGBD debe ser capaz de recuperarse de fallos hardware y software.

13) El SGBD debe proporcionar una forma simple de consultar los datos.

Características opcionales:

1) Herencia múltiple.

2) Comprobación de tipos e inferencia de tipos.

3) Sistema de base de datos distribuido.

4) Soporte de versiones.
Lenguaje ODL

El lenguaje de definición de datos (ODL) en un SGBDOO es empleado facilitar la portabilidad de los

esquemas de las bases de datos. 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. De esta forma un
esquema especificado en ODL puede ser soportado por cualquier SGBDOO que sea compatible con
ODMG-93.La sintaxis de ODL es una extensión de la del IDL (Interface Definition Language) desarrollado
por OMG como parte de CORBA (Common Object Request Broker Architecture).

La traducción ODL-C++, por ejemplo, se expresará como una librería de clases y una extensión a la
gramática estándar de C++. La librería de clases proporcionará clases y funciones para implementar los
conceptos definidos en el modelo de objetos, y la extensión consistirá en un conjunto de palabras
reservadas y su sintaxis asociada, que se añadirán a la declaración de clases de C++ para proporcionar un
soporte declarativo para las interrelaciones.

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 base de datos.

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.
 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.
 Existen dos posibilidades para asociar un sublenguaje de consulta a un lenguaje de
programación: fuerte y débilmente.
 El primer caso consiste en una extensión de la gramática del lenguaje asociado.
 En el segundo caso, las funciones query tienen unos argumentos String que contienen las
preguntas.

SGBDOO

Un Sistema de Gestión de Bases de Datos Orientadas a Objetos se puede decir que es un SGBD que
almacena objetos, permitiendo concurrencia, recuperación. Para los usuarios tradicionales de bases de
datos, esto quiere decir que pueden tratar directamente con objetos, no teniendo que hacer la
traducción a registros o tablas.

Las bases de datos tradicionales almacenan sólo datos, mientras que las bases de datos orientadas
a .objetos almacenan objetos, con una estructura arbitraria y un comportamiento. Una simple metáfora
(Esther Dyson) ayuda a ilustrar la diferencia entre ambos modelos. Consideremos el problema de
almacenar un coche en un garaje al final del día. En un sistema de objetos el coche es un objeto, el garaje
es un objeto, y hay una operación simple que es almacenar-coche-en-garaje. En un sistema relacional,
todos los datos deben ser traducidos a tablas, de esta forma el coche debe ser desarmado, y todos los
pistones almacenados en una tabla, todas las ruedas en otra, etc. Por la mañana, antes de irse a trabajar
hay que componer de nuevo el coche para poder conducir (problema: al componer piezas puede salir
una moto en vez de un coche).

Características de los SGBDOO

Un SGBDOO debe satisfacer dos criterios: Ser un sistema orientado a objetos, y ser un sistema de gestión
de bases de datos. El primer criterio se traduce en ocho características generales [BOO94]: abstracción,
encapsulación, modularidad, jerarquía, control de tipos, concurrencia, persistencia y genericidad. El
segundo criterio se traduce en cinco características principales: persistencia, concurrencia, recuperación
ante fallos del sistema, gestión del almacenamiento secundario y facilidad de consultas.

Ventajas e inconvenientes de las BDOO

Aunque los SGBDOO pueden proporcionar soluciones apropiadas para muchos tipos de aplicaciones
avanzadas de bases de datos, también tienen sus desventajas.

Las ventajas de un 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:

• Un objeto permite encapsular tanto un estado como un comportamiento.

• Un objeto puede almacenar todas las relaciones que tenga con otros objetos.
• Los objetos pueden agruparse para formar objetos complejos (herencia).

Ampliabilidad. Esto se debe a:

• Se pueden construir nuevos tipos de datos a partir de los ya existentes.

• Agrupación de propiedades comunes de diversas clases e incluirlas en una
superclase, lo que reduce la redundancia.
 • 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 mejor que los SGBDOO en las aplicaciones tradicionales de bases
de datos como el procesamiento de transacciones en línea (OLTP).

inconvenientes de un 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 encapsulación. 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
 BIBLIOGRAFÍA

Aguirre, R. (2014). Control de calidad en una empresa. Recuperado el 30-06-2019 de

https://www.gestionar-facil.com/control-calidad-una-empresa-crecimiento/.

Cabezón, S. (2014). Control de calidad en la producción industrial. Escuela de Ingenierías

Industriales. Universidad de Valladolid, pages 5–21.

Cadavid, P. and Hoyos, K. (2011). Reducción del nivel de desperdicio del proceso de produc- ción de la
galleta sultana bolsa en compañía de galletas noel sas. Facultad de Ingeniería.

Curra Sosa, D., García Lorenzo, M., and Bonet, I. (2009). Automation of the meter reading of ETECSA. PhD
thesis.

Daly, A. (2018). Reporte de sociedad nacional de las industrias. Recuperado el de 23-05-

2019 de http://www.sni.org.pe/.

Gonzáles, Rafael & Woods, R. (2008). Digital Image Processing. Prentice Hall.

ISO, S. C. (2015). Iso norma internacional. Sistemas de gestión de la calidad, 5:7–