Introducción
En una clase que estoy llevando en la universidad me han pedido hacer un ensayo sobre las bases de datos orientadas a objetos (qué tedioso fue, por cierto) pero al final lo he hecho, y como lo único que pasará con él es que será eliminado cuando termine yo de estudiar, mejor vengo a compartirlo para que ayude a alguien más y evite que se complique haciéndolo tanto como yo lo hice.
Sobre los derechos
El ensayo es mío, no es una pieza de arte ni algo así, pero te servirá si se lo presentas a tu profesor. También puedes leerlo simplemente por curiosidad.
Preséntalo como tuyo si quieres, siempre y cuando no me afecte a mí personalmente. ¿y cómo podría afectarme? bueno, no sabemos si estudias en el mismo lugar que yo, así que no puedes copiarlo si estudias en el mismo lugar que yo, en el mismo período de tiempo, ya que eso me afectaría.
Por otro lado, no me hago responsable de ninguna cosa. Lo pongo aquí al público pero no me hago cargo de cualquier cosa que salga mal, ya sea que la información esté mal, tenga faltas de ortografía (aunque soy muy, muy cuidadoso con ello, escribo código casi como escribo en la vida real 😉 es decir, muy bien) o esas cosas.
Ensayo sobre las bases de datos orientadas a objetos
Lo dejo como PDF por si realmente quieres leerlo:
Ensayo sobre las bases de datos orientadas a objetos
O como texto plano para copiar y pegar fácilmente…
Introducción
Las bases de datos son una pieza fundamental en todos los lugares en donde se implementan sistemas de información. Desde empresas gigantes como Apple, Facebook y Google, hasta en pequeñas y medianas empresas.
Cada uno de nosotros hace uso de ellas sin darnos cuenta: cuando compramos algo en el supermercado, haciendo una compra digital con una tarjeta de crédito, reservando un viaje, visitando una biblioteca, rentando una película, usando el internet e incluso estudiando en una universidad. Han llegado para quedarse y estarán aquí por un largo tiempo, pues la información es y será una pieza fundamental en cualquier área.
Debido a que cada día el tamaño de la información crece, los administradores de bases de datos (así como los desarrolladores y expertos en la materia) buscan la forma de crear sistemas más rápidos, confiables, optimizados y sobre todo fáciles de usar. Así es como las bases de datos orientadas a objetos nacen, por la necesidad de la mejora continua en la informática. Si bien la mayor parte del mundo utiliza bases de datos relacionales o bases de datos NoSQL, la orientación a objetos es un tema que promete mucho para el mundo digital.
Historia
En el inicio de la revolución informática, los datos eran guardados en ficheros de texto o archivos binarios en donde los datos eran guardados con una velocidad aceptable. El problema vino más tarde, cuando había miles o millones de registros que disminuían el rendimiento.
No fue hasta el año 1970 cuando Edgar Frank Codd (un investigador de IBM) publicó su trabajo llamado Un modelo relacional de datos para grandes bancos de datos compartidos (el título original en inglés es A Relational Model of Data for Large Shared Data Banks) en el cual especificaba un modelo relacional para la administración de bases de datos. En el documento, Edgar incluía entre otras cosas una especificación, formas normales y además un lenguaje llamado SEQUEL, que más tarde se convertiría en lo que conocemos hoy como SQL. Más tarde nacieron algunos, nuevos paradigmas (p. ej. NoSQL) y características ACID. Así fue como se definió de manera formal a una base de datos
Desarrollo
Una base de datos es un repositorio para datos; en otras palabras, se pueden almacenar montones de información en ellas. Por otro lado, una base de datos relacional es una base de datos especial que utiliza estructuras llamadas tablas, las cuales son enlazadas creando así lo que conocemos como relaciones.
Las ventajas que ofrecen estas bases de datos son que remueven la duplicidad de la información aplicando una técnica llamada normalización.
Los lenguajes de programación también evolucionaron. En ese punto recordamos primero al lenguaje ensamblador, en donde se tenía que programar dependiendo de las instrucciones que trajera incorporadas el procesador, ya fuera de Intel o de AMD (los primeros fabricantes).
Más tarde llegó el lenguaje C (claramente entre el ensamblador y él hubo muchos más) y su evolución: el lenguaje de programación C++. Aunque Simula fue el primer lenguaje de programación orientado a objetos, la popularidad de este paradigma se debe a su uso en los lenguajes de programación Java, C++ o C#. La programación orientada a objetos es un nuevo paradigma de programación que promueve la reutilización de código separando los conceptos en clases, a partir de las cuales se crean objetos. Los objetos se comunican con otros objetos a través de llamadas a funciones. Estos objetos también tienen propiedades que pueden definir por sí mismos o heredarlos de otros, haciendo uso de la herencia.
En este punto podemos observar la gran ventaja que tienen las bases de datos y la programación orientada a objetos. Si combinamos estas tecnologías podríamos crear un sistema gestor de bases de datos con las ventajas de: aislamiento, consistencia, durabilidad y atomicidad; además de guardar directamente objetos (y recuperarlos de igual manera) con las características de la POO como lo son el encapsulamiento, la herencia, el polimorfismo y la abstracción.
Una base de datos orientada a objetos (también llamada OODB por sus siglas en inglés) es manejada por un motor de bases de datos orientadas a objetos (llamado OODBMS) y el mismo debe ser capaz de proveer las características esenciales de una base de datos, identidad de objetos, encapsulamiento y objetos con un estado complejo. Todo ello a un nivel alto, facilitando su uso, pero siendo optimizado en los niveles más bajos.
En un escenario ideal, una base de datos orientada a objetos debería ser capaz de serializar los objetos para guardarlos ocupando el menor espacio posible, y hacer el proceso inverso al leerlos; cuidando que la operación realice el mínimo número de escrituras en memoria.
Un punto importante es que estas bases de datos deben tener las características que ya todos conocemos, como son la optimización de búsquedas a través de índices, gatillos, trabajos, copias de seguridad y restauración, vistas, procedimientos almacenados (aunque bien estos podrían ser hechos desde el lenguaje de programación), paginación (para limitar los resultados), agrupación y ordenamiento; sin mencionar cosas como la concurrencia o la replicación bidireccional.
Además, ni el programador ni el administrador deberían preocuparse por crear relaciones explícitas: cualquier clase podría heredar de otra clase, incluso de otras clases.
Mencionando otros aspectos, cada clase debería ser reutilizable y mantener el principio de responsabilidad única, el cual dice que cada clase debería encargarse de todo lo que tiene que ver con ella sin depender de alguien más.
No olvidemos los getters y los setters, ya que en las bases de datos relacionales seleccionamos las columnas que necesitamos, ahorrando almacenamiento, y en las bases de datos orientadas a objetos esto podría hacerse utilizando los métodos mencionados anteriormente para obtener únicamente algunas columnas. Algo muy importante es que un objeto (el cual se crea a través de una clase) no contiene únicamente propiedades, también tiene métodos que transforman a dichas propiedades. Hablando sobre objetos y miembros de los mismos, una base de datos de este tipo debería ser capaz de proteger a los miembros que le pertenecen dependiendo del clasificador, ya sea público o privado.
Lo más importante de todo esto es la seguridad, y para terminar pronto, un sistema gestor de este tipo debe tener una alta seguridad con usuarios y permisos de acceso. En niveles más bajos debe estar protegido contra desbordamientos de búferes, escalamiento de privilegios o accesos ilegales a la memoria.
Una ventaja que ofrecerían estos motores sería que ya no habría inyecciones SQL (tal vez habría incluso vulnerabilidades más peligrosas, pero ya no inyecciones) porque las consultas no serían simples concatenaciones, se utilizarían a los miembros de los objetos y se guardarían directamente sin ser procesados.
Conclusión
Desarrollar un motor de base de datos que sea capaz de abstraer objetos en lugar de relaciones es una tarea alcanzable, pero no por ello es fácil. Haciendo una comparación, una base de datos relacional puede traer datos en simples arreglos o vectores que fácilmente se pueden traducir a la mayoría de los lenguajes de programación. Sin embargo, la implementación de la orientación a objetos (aunque es un modelo para todos) dentro de las bases de datos cambiaría dependiendo del lenguaje que las consuman; tal vez un motor sería compatible únicamente con uno o pocos lenguajes.
Finalmente, en caso de conseguirlo debemos luchar con una cosa que todo administrador y programador debe tener en cuenta: el rendimiento. Como sabemos, un objeto es cargado en memoria cada que se consulta y debe crear relaciones en tiempo de ejecución, lo que disminuiría el tiempo de respuesta debido a la escritura en memoria. Todo ello hace que la orientación a objetos en las bases de datos sea un reto tanto de diseño como de optimización y rendimiento. Esperemos que, con la evolución de los microprocesadores, el estudio de la computación y el aumento de velocidad en las redes algún día sea posible crear un estándar que nos permita abstraer la orientación a objetos dentro de una base de datos sin mucho esfuerzo.
Borrador sobre el ensayo
Antes de tener el ensayo final, hice un borrador. Aquí lo dejo por si te sirve para sacar algo de información:
Introducción
Las bases de datos son una pieza fundamental en todos los lugares en donde se implementan sistemas de información. Desde empresas gigantes como Facebook y Google, hasta en medianas y pequeñas empresas.
Cada uno de nosotros hace uso de ellas sin darnos cuenta: cuando compramos algo en el supermercado, haciendo una compra digital con una tarjeta de crédito, reservando un viaje, visitando una biblioteca, rentando una película, usando el internet e incluso estudiando en una universidad.
Han llegado para quedarse y estarán aquí por un largo tiempo, pues la información es y será una pieza fundamental en cualquier área.
Debido a que cada día el tamaño de la información crece, los administradores de bases de datos (así como los desarrolladores y expertos en la materia) buscan la forma de crear sistemas más rápidos, optimizados y sobre todo fáciles de usar.
Así es como las bases de datos orientadas a objetos nacen, por la necesidad de la mejora continua en la informática. Si bien la mayor parte del mundo utiliza bases de datos relacionales o bases de datos NoSQL, la orientación a objetos es un tema que promete mucho para el mundo digital.
Historia
Para entender qué son las bases de datos orientadas a objetos, primero debemos entender qué son por separado los conceptos que componen al tema que estamos tratando aquí. Recordemos un poco sobre la historia de la computación.
Con la evolución de la informática las computadoras fueron un objeto más fácil de adquirir tanto para el uso personal como empresarial. Una computadora, si bien suponía un gasto, traía muchas ventajas a la hora de realizar operaciones que antes de ello eran hechas a mano.
Ahí fue donde las empresas buscaron la manera de guardar la información que tenían físicamente (en papeles, impresiones, archivos) de manera digital.
Entonces todos comenzaron a llenar el almacenamiento de las computadoras con información; empezamos con ficheros de texto o archivos binarios en donde los datos eran guardados con una velocidad aceptable, pero el problema vino más tarde cuando había miles o millones de registros que disminuían la velocidad de lectura/escritura, así como la combinación de los registros para obtener resúmenes.
Claro que los desarrolladores comenzaron a buscar maneras de optimizar el guardado y recuperado de información, pero todavía no había un estándar a seguir, ni siquiera un lenguaje o especificación; todos y cada uno de ellos hicieron lo mejor que pudieron, ya sea acompañados o individualmente.
No fue hasta el año 1970 cuando Edgar Frank Codd (un investigador de IBM) publicó su trabajo llamado Un modelo relacional de datos para grandes bancos de datos compartidos (el título original en inglés es A Relational Model of Data for Large Shared Data Banks) en el cual especificaba un modelo relacional para la administración de bases de datos.
En el documento, Edgar incluía entre otras cosas una especificación, formas normales y además un lenguaje llamado SEQUEL, que más tarde se convertiría en lo que conocemos hoy como SQL. La primera implementación comercial vino por parte de Oracle.
Me parece que todos sabemos el resto de la historia: llegaron otros motores (algunos comerciales, otros no), nuevos paradigmas (bases de datos NoSQL), características ACID y más cosas que veremos más adelante.
Ya vimos cómo evolucionaron las bases de datos hasta llegar a lo que son hoy en día, ¿pero qué hay acerca de la programación? antes de las bases de datos debió existir un lenguaje de programación, pues los datos no sirven para nada si no son procesados y presentados al usuario de una manera agradable y resumida a través de un intermediario
Recordemos primero al lenguaje ensamblador, en donde se tenía que programar dependiendo de las instrucciones que trajera el procesador. Más tarde llegó el lenguaje C (claramente entre el ensamblador y él hubo muchos más) y su evolución: el lenguaje de programación C++.
Aunque Simula fue el primer lenguaje de programación orientado a objetos, la mayoría de nosotros conoce este paradigma gracias al lenguaje de programación Java, C++ o C#. Más tarde este paradigma se incorporó a otros lenguajes como PHP, Python, JavaScript, Go, Rust, etcétera
¿y qué es la orientación a objetos? es un paradigma de programación en donde [aquí poner algo del libro de Java]
Ahora que estos dos conceptos han quedado claros, podemos observar la gran ventaja que tienen las bases de datos y la programación orientada a objetos, ahora bien ¿qué pasaría si combinamos estas dos tecnologías? podríamos crear un sistema gestor de bases de datos con las ventajas de: aislamiento, consistencia, durabilidad y atomicidad; además de guardar directamente objetos (y recuperarlos de igual manera) con las características de la POO como lo son el encapsulamiento, la herencia, el polimorfismo y la abstracción.
Todo esto suena bien, aunque la implementación está muy lejos de ser estandarizada.
Para continuar avanzando debemos saber cómo se define una base de datos formalmente.
Desarrollo
Una base de datos es un repositorio para datos; en otras palabras, se pueden almacenar montones de información en ellas. Por otro lado, una base de datos relacional es una base de datos especial que utiliza estructuras llamadas tablas, las cuales son enlazadas creando así lo que conocemos como relaciones.
Las ventajas que ofrecen estas bases de datos son que remueven la duplicidad de la información aplicando una técnica llamada normalización.
Listando algunos motores de bases de datos relacionales podemos mencionar al sistema gestor más popular: MySQL, cuya versión open source es MariaDB. Mirando hacia las licencias privativas vemos a SQLServer, el líder de bases de datos de Microsoft.
Esos son los más populares, pero hay más, por ejemplo PostgreSQL y SQLite que está presente en sistemas embebidos y en Android, por mencionar algunos dispositivos.
En un escenario ideal, una base de datos orientada a objetos debería ser capaz de serializar los objetos para guardarlos ocupando el menor espacio posible, y hacer el proceso inverso al leerlos; cuidando que la operación realice el mínimo número de escrituras en memoria.
Además, ni el programador ni el administrador deberían preocuparse por crear relaciones explícitas usando algún id: cualquier clase podría heredar de otra clase, incluso de otras clases.
Mencionando otros aspectos, cada clase debería ser reutilizable y mantener el principio de responsabilidad única, ese que dice que cada clase debería encargarse de todo lo que tiene que ver con ella sin depender de alguien más.
No olvidemos los getters y los setters, ya que en las bases de datos relacionales seleccionamos las columnas que necesitamos, ahorrando almacenamiento, y en las bases de datos orientados a objetos esto podría hacerse utilizando los métodos para obtener únicamente algunas columnas.
Algo muy importante es que un objeto (el cual se crea a través de una clase) no contiene únicamente propiedades, también tiene métodos que transforman a dichas propiedades.
Finalmente, pero no por ello menos importante, una base de datos de este tipo debería ser capaz de proteger a los miembros que le pertenecen dependiendo del clasificador, ya sea público o privado.
Conclusión
Desarrollar un motor de base de datos que sea capaz de abstraer objetos en lugar de relaciones es una tarea alcanzable, pero no por ello es fácil.
Para empezar, una base de datos relacional puede traer datos en simples arreglos o vectores que fácilmente se pueden traducir a la mayoría de los lenguajes de programación.
Sin embargo, la implementación de la orientación a objetos (aunque es un modelo para todos) dentro de las bases de datos cambiaría dependiendo del lenguaje que las consuman; tal vez un motor sería compatible únicamente para uno o pocos lenguajes.
Finalmente, en caso de conseguirlo debemos luchar con una cosa que todo administrador y programador debe tener en cuenta: el rendimiento. Como sabemos, un objeto es cargado en memoria cada que se consulta, debe crear relaciones en tiempo de compilación, además de que las operaciones en memoria disminuyen la velocidad de respuesta.
Todo ello hace que la orientación a objetos en las bases de datos sea un reto tanto de diseño como de optimización y rendimiento.
Esperemos que con la evolución de los microprocesadores, el estudio de la computación y el aumento de velocidad en las redes algún día sea posible crear un estándar que nos permita abstraer la orientación a objetos dentro de una base de datos sin quebrarnos mucho la cabeza.
https://docs.oracle.com/cd/B13789_01/server.101/b10759/intro001.htm
http://web.eecs.utk.edu/~huangj/CS302S04/notes/oo-intro.html
http://www.utn.edu.ec/reduca/programacion/poo/pilares.html
