2. Historia
Las ideas básicas de la orientación a objetos nacen a principios de los
años 60 en la universidad de Noruega. Un equipo dirigi-do por el Dr.
Nygaard se dedicaba a desarrollar sistemas infor-máticos para realizar
simulaciones de sistemas físicos como simular el funcionamiento y obtener
el rendimiento de un motor. La dificultad en la que se encontraban era
doble. Por un lado los programas eran muy complejos y, por otro,
forzosamente tenian que ser muy modificados. Este segundo punto era
especialmente problemático, ya que la razón de ser de los programas era
el cambio y no sólo se requerían varias iteraciones para obtener un
producto con el rendimiento deseado, sino que muchas veces se querían
obtener diversas alternativas viables cada una con sus ventajas e
inconvenientes.
3. La solución que idearon fue diseñar el programa paralelamente al objeto físico.
Es decir, si el objeto físico tenía cien componentes, el programa también
tendría cien módulos, uno por cada pieza. Partiendo el programa de esta
manera, había una total correspondencia entre el sistema físico y el sistema
informático. Así, cada pieza física tenía su abstracción informática en un
módulo. De la misma manera que los sistemas físicos se comunican
enviándose señales, los módulos informáticos se comunicarían enviándose
mensajes.
Este enfoque resolvió los dos problemas planteados. Primeramente, ofrecía
una forma natural de partir un programa muy complejo y, en segundo lugar, el
mantenimiento pasaba a ser controlable. El primer punto es obvio ya que, al
partir el programa en unidades informáticas paralelas a las físicas, la
descomposición es automática. El segundo punto también se resuelve ya que,
a cada iteración de simulación, el analista querrá cambiar o bien piezas enteras
o bien el comportamiento de alguna pieza. En ambos casos la localización de
los cambios está perfectamente clara y su alcance se reduce a un
componente, siempre y cuando el interfaz del mismo no cambie. Por ejemplo,
si se estuviese simulando un motor o coche, puede que se quisiera modificar el
delco utilizado en la simulación anterior. Si el nuevo delco tuviera la misma
interfaz (mismos inputs y outputs) o se cambiase sólo su comportamiento
interno, nada del sistema (fuera del delco) estaría afectado por el cambio.
4. Las bases de datos orientadas a objetos, fue un tema que se pensó, que
revolucionaría la manera de hacer persistente la información en los
sistemas software durante los años 90. En la actualidad es evidente que esto
no fue así. Sin embargo, un resurgimiento de este concepto, gracias a las
comunidades de software libre, y la identificación de aplicaciones idóneas para
el mismo, motivan la revisión de las características de esta alternativa a las
omnipresentes bases de datos relacionales. Las bases de datos orientadas a
objetos se crearon para tratar de satisfacer las necesidades de estas nuevas
aplicaciones.
La orientación a objetos ofrece flexibilidad para manejar algunos o de estos
requisitos y no están limitadas por los tipos de datos y los lenguajes de
consulta de los sistemas de bases de datos tradicionales. Una característica
clave de las bases de datos orientadas a objetos 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.
Otro motivo para la creación de las bases de datos orientadas a objetos es el
creciente uso de los lenguajes orientados a objetos para desarrollar
aplicaciones.
5. CONCEPTOS
Una base de datos orientada a objetos es una base de datos inteligente
soporta el paradigma orientado a objetos almacenando métodos y datos, y no
solamente datos. Esta diseñada para ser eficaz, desde el punto de vista físico,
para almacenar objetos complejos. Evite el acceso a los datos; esto gracias a
los métodos almacenados en ella. Es mas segura, ya que no permite tener
acceso a los datos (objetos); esto debido a que para poder entrar se tiene que
hacer por los métodos que haya utilizado el programador.
6. VENTAJAS Y DESVENTAJAS
Ventajas:
Mayor capacidad de modelado
Ampliabilidad
Lenguaje de consulta más expresivo.
Adecuación a las aplicaciones avanzadas de base de datos.
Mayores prestaciones.
7. Desventajas:
Carencia de un modelo de datos universal.
Carencia de experiencia.
Carencia de estándares.
Competencia. Con respecto a los SGBDR y los SGBDOR.
La optimización de consultas compromete la encapsulación.
El modelo de objetos aún no tiene una teoría matemática coherente que le
sirva de base.
8. BDOO VS BDR
El modelo objeto difiere en este sentido bastante. Utiliza varios sistemas diferentes
dependiendo de la implementación que se esté utilizando.
Hay sistemas, directamente imbuidos en el lenguaje de programación que hacen
esta recuperación de los datos transparente al programador, trabajando con los
objetos persistentes como si fueran objetos de memoria normales.
Otra forma de implementar las consultas ha sido el estándar OQL (Object Query
Language) definido por el Object Data Management Group (ODMG) que busca ser
un estándar declarativo para consultas a bases de datos orientadas a objetos.
La forma de trabajar con los datos persistentes en el modelo relacional es
seleccionando los datos que queremos que persistan en el tiempo y grabándolos
de manera explicita mediante consultas de alta/modificación de SQL, previa
transformación de los datos.
9. El modelo relacional utiliza el concepto de Clave Primaria para identificar a sus
entidades de una manera única. Los modelos relacionales tradicionales sólo
permitían tipos de datos simples ofrecidos por SQL y en última instancia por el
sistema gestor. Los modelos relacionales utilizan el lenguaje estándar de
consultas SQL, que es declarativo lo que hace que las consultas no vayan a la
forma de encontrar el dato sino que sea el sistema gestor el que realice esta
tarea. El modelo objeto, por definición provee de un sistema de tipos análogo al
lenguaje de programación con el que se utiliza.