Vous êtes sur la page 1sur 5

TEMA 2

Concepto de bases de datos. Sistemas de gestión de bases


de datos relacionales. Sistemas de gestión de bases de datos
orientados a objetos.

Una aplicación informática consta de dos componentes principales que


colaboran para llevar a cabo la funcionalidad que el usuario desea. El primero
de estos componentes es la base de datos, que guarda la información
necesaria para operar la aplicación, en forma de datos en disco. El segundo
componente es el programa propiamente dicho, que recupera esos datos de la
base de datos, realiza los cálculos necesarios y presenta los resultados
deseados al usuario.

datos
PROGRAMA Base de Datos

datos

Para que estos dos componentes puedan funcionar juntos deben poder
comunicarse intercambiando datos. En otras palabras, deben de ser
compatibles. Sin embargo, durante los últimos treinta años la evolución de
estos dos componentes ha sido divergente, de forma que cada vez se ha
hecho más difícil que colaboren en una misma aplicación.
Así, desde los años setenta a la actualidad, las bases de datos utilizan un
modelo teórico llamado “relacional”, que se ha convertido en un estándar y que
es utilizado en la práctica totalidad de aplicaciones de software.

En cambio, los programas han usado, desde los años ochenta, un modelo
llamado "orientado a objetos", que difiere en mucho del modelo relacional y que
se ha extendido cada vez más. Es por ello que aparece un conflicto a la hora
de reunir estos dos componentes en una aplicación, ya que cada uno responde
a diferente modelo y forma de operar. Cada componente maneja los datos con
un formato diferente. Metafóricamente, podríamos afirmar que el programa y la
base de datos hablan idiomas diferentes y, por lo tanto, la comunicación entre
ellos resulta difícil.

En este apartado veremos una descripción de los dos modelos mencionados y


de las diferencias que dificultan su combinación en una sola aplicación. A
continuación, se exploran las diferentes soluciones a este problema y se acaba
concluyendo que la mejor manera de resolverlo es usando un motor de
persistencia. Terminamos mencionando los nombres de los motores de
persistencia más usados, con el fin de que el lector tenga una idea de las
opciones más utilizadas en la actualidad.

MODELO ORIENTADO A OBJETOS

El modelo orientado a objetos es el modelo teórico que usa la mayoría de los


programas actuales. La programación orientada a objetos hunde sus raíces en
los años sesenta (en los que aparecieron los primeros lenguajes de este tipo,
llamados Simula 1 y Simula 67, desarrollados en el Centro Noruego de
Computación, en Oslo). En los primeros setenta, aparece Smalitalk, un
lenguaje fundamental en la historia de la orientación a objetos.

Sin embargo, no es hasta la segunda mitad de los años ochenta cuando la


orientación de objetos se generaliza, convirtiéndose en el estándar
predominante en los años noventa, de la mano de lenguajes como C+ + y
Java. El triunfo de la programación orientada a objetos ha sido impulsado por
la enorme difusión de otras tecnologías (como la interfaz gráfica o las
arquitecturas distribuidas) que son más fáciles de implementar mediante este
tipo de desarrollo que mediante una programación tradicional.

Hoy en día, la práctica totalidad de los lenguajes de programación que surgen


son orientados a objetos y esta tecnología se ha convertido en el estándar
actual de programación que, a su vez, está generando nuevos desarrollos muy
prometedores para el futuro (como, por ejemplo, la programación orientada a
aspectos).

La idea de la orientación a objetos es modelar los programas de una forma


parecida a como percibimos la realidad. Para la mente humana, el universo
está compuesto por una serie de objetos (en el sentido más amplio de la
palabra, incluyendo seres vivos, ideas, etc.). Cada objeto tiene unas
características que lo diferencian de los demás y, con cada objeto, se pueden
realizar unas acciones que son propias y especificas del mismo.

Así, por ejemplo, un determinado automóvil tiene unas características (color


rojo, caja de cambios automática, diesel, etc.) y puede realizar unas
determinadas acciones (acelerar, frenar, etc.).

La programación orientada a objetos intenta modelar estos objetos reales con


estructuras de programa, llamadas objetos de software o simplemente objetos.
Cada uno de estos objetos de software, está compuesto por una serie de
características (atributos) y una serie de acciones (métodos), al igual que
un objeto de la vida real.
El modelo orientado a objetos es un modelo que incluye tanto la parte estática
de un objeto (los atributos, es decir, sus características) como su parte
dinámica (los métodos, es decir, sus acciones). Incluye tanto los datos como
los procesos.

La programación orientada a objetos se basa en la realidad. Su mayor ventaja


es que simplifica el mantenimiento de los programas y hace posible programar
y mantener hasta los programas más enormes al dividirlos en partes más
pequeñas, es decir, en objetos. Como consecuencia, produce reducciones de
costos y mayor calidad del código y se ha convertido en el estándar actual de
programación.

MODELO RELACIONAL

Muy ajeno a la revolución que supuso la orientación a objetos, el área de las


bases de datos sigue fiel a un modelo antiguo pero que ha probado su eficacia:
el llamado modelo relacional. Desde los años 70 es un estándar universal para
el acceso a datos, dominando totalmente el área de las bases de datos hasta la
actualidad.
El modelo relacional sólo se ocupa de la parte estática de la aplicación (datos)
y no de la parte dinámica (procesos).
La forma en la que este modelo trata a los datos también es muy diferente a
como lo hace el modelo orientado a objetos. En el modelo relacional los datos
no son tratados como objetos (como en el modelo anterior) sino como registros:
serie de datos pertenecientes a una misma entidad de la vida real.
Un registro difiere de un objeto en que sólo modela datos y que éstos no tienen
estructura.
Los registros similares se agrupan en tablas: listados de datos. Cada registro
sería una línea del listado.
El modelo relacional no refleja la estructura de la realidad. El programador debe
saber que hay una relación entre los datos y los procesos, y debe programar de
acuerdo a ello. Sin embargo el modelo no refleja explícitamente esta relación y,
en general, la estructura de la realidad. Al contrario del modelo orientado a
objetos.

APLICACIONES TRADICIONALES.

Una aplicación está formada por un programa y por una base de datos que se
comunican entre sí. El programa suele estar diseñado según el modelo
orientado a objetos y, por lo tanto, trabaja con datos en formato de objetos. Por
el contrario, la base de datos está diseñada según el modelo relacional y, por lo
tanto, trabaja con datos en formato de registros.
Esto introduce una dificultad importante, porque los dos formatos de datos
(objetos y registros) son incompatibles entre sí. Así cuando el programa quiere
guardar o recuperar los datos en disco, lo hace en forma de objetos, pues es el
formato de datos que conoce. Sin embargo, la base de datos no puede guardar
o recuperar objetos, pues está diseñada para guardar o recuperar registros (y
no objetos), que es el formato de datos que ella reconoce.
La solución más obvia a este problema es hacer que uno de los componentes
hable el idioma del otro. Es decir, que un componente use el formato de datos
del otro.
Esta era la forma de programar universalmente antes de la aparición de la
orientación a objetos y sigue siendo la arquitectura dominante en muchos
ámbitos. Aún en las empresas que utilizan lenguajes orientados a objetos, la
mayoría programa sin tener en cuenta la orientación a objetos a la hora de usar
los datos, los cuales se gestionan de forma relacional.
El problema de esta arquitectura es que se desaprovechan las grandes
ventajas de flexibilidad, facilidad de mantenimiento y facilidad de gestión de
sistemas complejos que da la programación orientada a objetos. Asimismo, el
código que opera con datos relacionales suele ser complejo, difícil de mantener
y de ampliar y muy dependiente de la estructura de los datos.

BASES DE DATOS ORIENTADAS A OBJETOS.

Si toda la aplicación tiene un único modelo teórico, el de la orientación a


objetos, ello implica que el formato de datos que usa toda la aplicación es el
formato de objetos.
Las bases de datos orientadas a objetos guardan y recuperan objetos. Por lo
tanto, la comunicación de este tipo de bases de datos con un programa
orientado a objetos es posible.
Pero surgen complicaciones derivadas del hecho de que las actuales bases de
datos orientadas a objetos no están tan afirmadas como sus homólogas
relacionales y, por lo tanto, no gozan de la abundancia de herramientas, la
fiabilidad, facilidad de administración y rendimiento de estas últimas.
Lo que es peor, las bases de datos orientadas a objetos frecuentemente son
incompatibles entre sí. Esto hace imposible migrar una aplicación desde una
base de datos orientada a objetos a otra lo que nos obliga a depender de un
único proveedor (vendor lock-in) con todo lo que ello supone: aumentos de
precio, falta de soporte si el proveedor sale del mercado, etc.
Aunque esta opción es la preferible en un futuro, actualmente resulta
arriesgado aplicarla, ya que aún no posee la madurez y estandarización
suficientes.

MOTORES DE PERSISTENCIA

Si el programa de una aplicación está orientado a objetos y la bases de datos


sea relacional, hay que contar con un traductor que sepa traducir de un idioma
a otro. Este traductor en el mundo de la programación se conoce como: capa
de persistencia, o capa de datos, o correspondencia O/R (OR mapping), o
motor de persistencia.
El motor de persistencia traduce entre los dos formatos de datos: de registros a
objetos y de objetos a registros.

El programa sólo considera que pueda guardar y recuperar objetos. La base de


datos sólo aprecia que guarda registros y recupera registros. Cada uno de los
dos componentes trabaja con el formato de datos que le resulta más natural, y
es el motor de persistencia el que actúa de “traductor” entre los dos modelos,
permitiendo que los dos componentes se comuniquen y trabajen
conjuntamente.

Ventajas:
Se puede programar con orientación a objetos, aprovechando las ventajas de
flexibilidad, mantenimiento y reusabilidad.
Se puede usar una base de datos relacional aprovechando su madurez y
estandarización así como las herramientas relacionales existentes actualmente.

Un motor de persistencia puede reducir el código de una aplicación en un 40%,


haciéndola menos costosa de desarrollar. Además el código que se obtiene
programando de esta manera es más limpio y sencillo y por tanto más fácil de
mantener y más robusto.
Además de simplificar la programación, el motor de persistencia permite hacer
ciertas optimizaciones de rendimiento que serían difíciles de programar por
nosotros mismos.

Otra ventaja del motor de persistencia es que es el mismo para todas las
aplicaciones. De esta forma sólo debe programarse una vez y puede usarse
para todas las aplicaciones que se desarrollen en nuestra empresa. Sin
embargo, un motor de persistencia es difícil de programar y de mantener, por lo
que necesita un gran esfuerzo en costo y tiempo de desarrollo.

Existen dos opciones a la hora de usar un motor de persistencia:


- Programarlo dentro de la propia organización, lo que conlleva
gran complejidad y costos.
- Utilizar un motor que ya esté programado, comprándolo a un
vendedor o bien usando un motor gratuito de código abierto.

Lo recomendable es, a todas luces, la segunda opción.