Generaciones de Bases de Datos (un poco de historia)
Cuando hablamos de bases de datos, en nuestras conversaciones nos
referimos a datos relacionales. Esto no fue siempre así, antes que el
modelo relacional fuese desarrollado, existió otro modelo de datos.
Ahora,
el caso para considerar las alternativas ha llegado a ser cada vez más
fuerte, con las nuevas generaciones de leguajes de desarrollo
orientados a objetos se abre una gama de oportunidades a las
aplicaciones, y a su vez a las base de datos con la aparición de las
bases de datos nativas, orientadas a guardar estos objetos creados por
las aplicaciones.
Antes de que el primer DBMS fuese
desarrollado, las aplicaciones se conectaban a orígenes de datos de
“ficheros planos”. Éstos no permitir la representación de las
relaciones de los datos o de la aplicación lógicas de la integridad de
los mismo. El modelar de los datos se ha desarrollado desde los años 60
para proveer características de gran alcance del almacenaje de datos.
Generalmente
hablando, los modelos de los datos se han desarrollado en tres
generaciones. La primera generación de modelos de los datos se tiende a
rechazar sin embargo fue el origen o génesis de las base de datos.
Hasta el momento, las bases de datos más comercialmente aceptada han
sido las bases de datos de segunda generación que utilizan el modelo
relacional. Las bases de datos relacionales son definitivamente las que
poseen la mayor parte del mercado “por ahora” lo que ha hecho muy
difíciles para una nueva generación de bases de datos, conseguir por lo
menos un equilibrio entre las dos generaciones. Sin embargo, el mundo
de los lenguajes programación o desarrollo ha venido cambiado. Con la
evolución nuevas plataformas como lo son Java y de Microsoft con .NET,
entre otras. Las opciones del desarrollador cada vez más amplias y
poder elegir el modelo de datos a utilizar, entre el modelo orientado
objetos y el modelo no orientado a objetos.
Bueno no hablemos más y comencemos con esta pequeña pero instructiva clase de historia. – no se me duerman por favor -
PRIMERA GENERACION: Modelo Jerárquicos y Red
La
aparición de los sistemas informáticos en los años 60 condujo al
desarrollo de modelos de datos jerárquicos y modelos de los datos de la
red, que se refieren generalmente como los modelos de primera
generación de los datos.
El modelo Jerárquicos
La
mayoría de los usuarios de la computadora están familiarizados con una
forma jerárquica de almacenamiento de la información. El sistema de
archivos utilizado por la mayoría de los sistemas operativos del PC, es
un ejemplo de una jerarquía y en consecuencia, esto se conoce como el
modelo de datos jerárquico. Representa directorios y archivos como un
sistema de árboles. Características:
- Permite uno a uno, o
uno a muchos relaciones entre entidades, de un directorio o carpeta
puede contener un archivo, o que puede contener muchos archivos (o tal
vez no contienen los archivos).
- Una entidad en una "muchos"
final de una relación que puede estar relacionado con una sola entidad
en el "uno" final, en otras palabras, un archivo sólo puede ser en un
solo directorio.
Este modelo de almacenamiento es a
menudo descrito como de “NAVEGACION”. Esto significa que para encontrar
un tema en particular, tiene su manera de navegar a través de la
jerarquía usando predefinidas relaciones hasta llegar a él dato que se
desea. Esto puede ser muy eficaz si las consultas que desea hacer
cumplen con esta relación. Sin embargo, puede ser muy ineficiente si se
va a consultar sus datos en forma especial, por ejemplo, una búsqueda o
consulta que desee hacer un usuario, la cual no se diseño con
anticipación en la base de datos. Si la información que desea encontrar
en un sistema de ficheros que figura en varios archivos en directorios
diferentes, entonces el proceso de recolección puede ser muy laborioso.
Cada
cliente puede tener muchos pedidos, y cada pedido puede contener muchos
elementos. Cada elemento pertenece a un orden particular, y sólo en ese
orden.
Las
bases de datos jerárquicas, que eran la primera generación de bases de
datos, almacenan sus datos de esta forma. La base de datos jerárquica
más conocida IBM’s Information Management System (IMS), que ha estado
desde los años 60 y todavía es apoyado por IBM.
El Modelo de Dato de Red
El
estándar del modelo de los datos de red fue desarrollado en a finales
de los años 60 por el the Committee on DataSystems Languages (CODASYL),
la misma organización que desarrolló COBOL. Agregó una característica
importante para modelar de los datos. La familia múltiple, significa
que una sola entidad puede estar en los “muchos” finales de relaciones
múltiples. Esto es un pedacito más difícilmente a imaginarse en
términos de sistema de archivos, significaría que un archivo podría
estar en más de un directorio al mismo tiempo. En muchos panoramas, el
modelo de la red permitió que los datos fueran modelados más realista.
El
modelo de la red dio un grado adicional de flexibilidad en los datos
que se modelaban, pero seguía siendo a modelo un modelo “NAVEGACIONAL”.
La red define un sistema de relaciones, y tienes que seguirlas.
Los
modelos de primera generación no eran adecuados para consultas
especiales, en el que no necesariamente sabe cómo los datos tendrán que
ser recuperados antes de crear la base de datos.
SEGUNDA GENERACION DE BASES DE DATOS.: MODELO RELACIONAL
El
modelo relacional, sin duda, ha sido el más utilizado y con éxito mayor
comercial hasta la fecha de modelado de datos. Sus características son
muy diferentes de los modelos anteriores. Para empezar, los datos de
las entidades están representados por estructuras simples en forma de
cuadro, conocido como relaciones. Entidad relaciones y la integridad de
los datos se definen mediante claves primarias y claves foráneas. El
diseño de una base de datos relacional se basa en la idea de la
normalización, el proceso de eliminación de los datos redundantes de
sus cuadros, a fin de mejorar la eficiencia de almacenamiento, la
integridad de los datos y escalabilidad
El modelo relacional fue
propuesto en 1970 por Edgar Codd para representar a la estructura
física de los datos sin que el usuario de base de datos que necesitan
saber acerca de la máquina de la representación. Se promovió la idea de
usuario final y la programación interactiva de consultar una base de
datos. Esto fue un gran paso adelante en la capacidad de utilización de
las bases de datos.
Accesando el Modelo Relacional
Acceso
a los datos utiliza un alto nivel nonprocedural del lenguaje (SQL).
Esto hace que las bases de datos relacionales de gran especialidad en
lo que a consultas se refiere. Si los datos que se exigen en la base de
datos, vas a ser capaz de escribir una consulta SQL que lo recoja,
aunque puede incorporarse a la participación de muchas tablas para
obtener los datos.
Select Cantidad from ORDENES
where TipoDocumento='01' and Costo > 1250
SQL
ha evolucionado de una norma que cuenta con el apoyo de la mayoría de
los productos comerciales de base de datos, aunque por lo general los
productos añaden sus propias extensiones propietarias del lenguaje.
Las
consultas se construyen basada en la rama de las matemáticas conocida
como teoría de conjuntos, aunque no necesitamos saber los detalles de
la teoría de conjuntos para escribir sentencias SQL.
El modelo
relacional las consultas no son de tipo de navegación. No tiene que
seguir trayectorias predefinidas. Puede escribir una consulta SQL para
seleccionar datos de cualquier tabla en una base de datos. Si desea
obtener los datos de más de un tipo de entidad, puede escribir sus
consultas de unión de las tablas. Por lo general, se unen varias tablas
para realizar una consulta de datos, mostrando los nombres de los
campos comunes y condiciones que deben cumplirse todo esto es mostrado
en una sola tabla o vista de datos. No existe una dirección implícita,
por lo que no existe el concepto de la navegación de un cuadro a otro.
Modelo Relacional con Programación de Procedimientos
Bases
de datos relacionales son una gran adaptación de los programas de
procedimiento. Puede utilizar aplicaciones de modelado para el diseño
de su esquema de base de datos y ver asi como se mostraran los datos,
también podemos escribir todo una serie de instrucciones SQL en un
bloque, esta recibirá algunos datos, ejecuta esta serie de
instrucciones y agrega o actualiza o elimina los datos. La aplicación
depende en gran medida de la base de datos de diseño. Puede conectarse
a la base de datos desde una aplicación escrita en cualquier lenguaje
de programación, que se puede obtener un proveedor o cliente para una
base de datos especifica. La misma base de datos puede ser el objetivo
para distintas aplicaciones.
SQL no es un lenguaje de
programación completo, de modo que no puede escribir una aplicación con
el mismo. Su trabajo consiste en expresar las consultas o preguntas y
realizar alguna manipulación de los datos de la base de datos. Como
resultado de ello, ya sea SQL es utilizado en un prompt interactivo o
más comúnmente, aparece como cadenas de texto incrustado dentro de otro
lenguaje. Por supuesto, muchos sistemas de bases de datos relacionales
tienen la capacidad de utilizar procedimientos almacenados, que son
módulos de programas que existen en el DBMS, como el mencionado
anteriormente.
Pienso que estos DBMS, tienen la necesidad de
combinar con otro lenguajes SQL, tales como Oracle PL / SQL. El uso de
cadenas SQL embebido en el código de aplicación externa a la base de
datos puede presentar un problema para los desarrolladores. El
compilador simplemente interpreta estos como cadenas de texto, si es un
válido, la cadena entonces está bien en la medida de lo que el
compilador se refiere. Tal vez sería completa sin sentido en la medida
como la base de datos se refiere: puede hacer referencia a tablas o
columnas que no existen, por ejemplo. Usted tiene que esperar hasta que
el runtime (tiempo de ejecución) para comprobar que de verdad funciona
esta instrucción o muestra algún error, y muchas veces esto hace la
depuración un poco difícil.
Modelo Relacional con Programación Orienta a Objetos
Orientado
a objetos tratan de los sistemas modelo en el dominio del problema
términos de los objetos. Las entidades del sistema se describen en un
diagrama de clase, en lugar del diagrama de entidad relacional, del
sistema tradicional. De repente, la base de datos no es el manejador de
la aplicación - en lugar de ello, su función primordial es la de
proporcionar un servicio a la solicitud y no la del conocimiento de
persistencia de los objetos. Este cambio es importante, porque de las
diferencias entre el objeto y el modelo relacional de datos. La
herencia no está directamente apoyada en el modelo relacional.
Hay
algunas variaciones significativas entre RDBMSs en sus características,
incluyendo su apoyo a Orientación a objetos. PostgreSQL RDBMS ahora la
tabla de características herencia, polimorfismo, en la que apoya
Consultas o Query. Esta no es, sin embargo, una capacidad estándar de
RDBMS
Un resultado de esto es visto a menudo cuando los sistemas
orientados a objetos se crean dentro de una structura de datos ya
definida. El modelo de objetos se ve limitado a fin de que el diagrama
de clase coincida con la de base de datos del diseñador. Esto rara vez
se produce un buen modelo de objetos. El problema de SQL embebido,
cadenas también se aplica a los programas orientados a objetos, quizás
más que como herramientas de apoyo y fácil refactorización, no se
pueden entender o modificarlas.
TERCERA GENERACION: Modelo Post-Relacional (Yo lo llamo objetos)
La
tercera generación de modelos, se propuso por primera vez en el decenio
de 1980, son una respuesta a los problemas que suelen surgir cuando se
casa o unen con un sistema orientado a objetos a una base de datos
relacional. A veces son descritos como "después de relaciones", aunque
es más realista considerar como coexistir con el modelo relacional y la
presentación de más opciones para los desarrolladores. A diferencia de
la segunda generación, donde el modelo relacional es bastante
universalmente adoptados, con algunas variaciones de propiedad, la
orientación a objetos de tercera generación se ha desarrollado en dos
direcciones distintas, de las cuales les comentare un poco.
El Modelo de Objeto
El
Modelo de Objetos de datos es prácticamente el mismo que el paradigma
orientado a objetos, excepto que los objetos son persistentes. Es
decir, que siguen existiendo después de que el programa termina la
ejecución y sale de memoria.
Un objeto en la base de datos es un
objeto análogo, a un objeto en la aplicación de memoria. En la mayoría
de las bases de datos objeto, poseen un majedor que las une con el
lenguaje de programación, que le permiten usar la persistencia de
objetos en las aplicaciones. Una aplicación Java requiere un lenguaje
vinculante, con la base de datos de objetos y así sucesivamente. El
esquema de base de datos en sí es un objeto creado usando definición
del lenguaje en el cual fue desarrollada la clase, que define los
objetos que pueden ser almacenados, y de sus relaciones.
Los
objetos son almacenados exactamente como son creado en la solicitud.
Las bases de datos nativas de objeto no necesitan una definición del
lenguaje o regla o estructura – Su esquema de la base de datos es
idéntico al modelo de dominio del objeto que realizo la solicitud. Son,
Por lo tanto, estrechamente vinculados a las aplicaciones que los
utilizan. Imaginemos el objeto como un sello húmedo, y la base de
datos es el papel donde colocamos el sello, es decir la persistencia de
esa información que se encuentra en el sello.
Origenes de la Bases de Datos de Objetos
La
base de datos orientada a objetos emergen de un manifiesto escrito por
Malcolm Atkinson y otros en 1989, que especifica una lista de
requisitos que debe cumplir una base de datos de objetos, incluidos
algunos orientado a objetos de bases de datos y algunas características
similares a las funciones. La base de datos de Object Management Group
(ODMG) trató de establecer normas para bases de datos de objetos,
incluida la educación abierta ya distancia, como definición de un
lenguaje de objetos, y OQL, un lenguaje de consultas de objetos. Estas
normas han sido adoptadas en cierta medida, pero nunca han logrado
aceptación universal. La versión final de la ODMG estándar, ODMG 3,0,
fue puesto en libertad en 2001, “cuando escribi este articulo la ODMG
esta pensando en una 4ta Generacion, orientada a facilitar un poco la
transición paradicmatica de los objetos a las base de datos de objetos”.
El Modelo Objeto a Relacional
Casi
al mismo tiempo que el modelo de datos de objeto que se propone, el
problema de almacenamiento de objetos en las bases de datos se estaba
enfocando desde un ángulo diferente. El objeto de modelo relacional
extiende las capacidades del modelo relacional para permitir que los
objetos que se almacenan en las columnas de una base de datos
relacional. Un objeto relacional DBMS que a veces se denomina un
híbrido DBMS.
“Un híbrido enfoque del DBMS, fue propuesto por
Michael Stonebraker en 1990, y se ha aplicado en algunos comerciales
RDBMSs, incluidos Oracle. La motivación fue el deseo de las bases de
datos que puede almacenar complejas entidades y normas, pero que
conserva todas las ventajas de la segunda generación de bases de datos.”
El objeto de modelo de datos relacional es una extensión del modelo relacional, con las siguientes características
- Un campo puede contener un objeto con atributos y operaciones.
- Complejo objetos pueden ser almacenados en las tablas relacionales
Por
ejemplo, Oracle apoya la posibilidad de declarar un nuevo tipo de datos
que es básicamente una clase, y para establecer este nuevo tipo como el
tipo de datos de una columna de la tabla.
El modelo de objeto de los
datos relacional, su enfoque es bastante contrario de lo que las bases
de datos de objeto, en particular con respecto a las nativas, lo que
están tratando de lograr. En lugar de dar la capacidad de persistencia
de un sistema orientado a objetos, que proporciona capacidades
orientado a objetos dentro de la base de datos. Este enfoque no es el
adecuado para aplicaciones incrustadas por el que muchas bases de datos
de objetos, sobresale. Como usted necesita un verdadero RDBMS a hacer
uso de ella.
El uso de términos como "tercera generación" y "después
de relaciones" no ha sido particularmente precisado, que implicaba que
este tipo de bases de datos que se sustituya las bases de datos
relacionales, la forma en que la segunda generación efectivamente ha
suplantado a la primera. La tercera generación no ha tenido el lugar de
las bases de datos relacionales, sino que existe en forma paralela a
ampliar las posibilidades abiertas a los desarrolladores a usar las
soluciones adecuadas para sus propias aplicaciones.
Colocación de Objetos en una Base de Datos Relacional
Si
el diseño de un sistema orientado a objetos es manejado por la
aplicación en lugar de ser manejado por los datos, entonces la base de
datos necesita disponer de un medio de persistir los objetos en el
sistema. Si la base de datos relacional, requiere un mapeo de objetos a
tablas de la base de datos. Este requisito existe independientemente
del mecanismo que se usa para permitir que una aplicación se comunique
con la base de datos (ya sea fuerte código SQL dentro de la aplicación
o de una capa de mapeo de datos como Hibernate)
Esto puede ser a
veces una simple cuestión de la mapeo de clases individuales por
separado a las tablas de base de datos. Sin embargo, si la estructura
de clases es más compleja, entonces el mapeo debe considerarse
cuidadosamente los datos para permitir a hacerse representar y acceder
de la forma más eficiente posible. Buscando estrategias relacionales de
mapeo entre el objeto y la base de datos relacional, con el fin de
obtener un objeto robusto y rápido a su vez.
Objetos con ODBMS vs Objeto con RDBMS, fuente de la imagen German Viscuso.
Queries o Consultas
Consultas
usando SQL es una capacidad fundamental de una base de datos
relacional. Atkinson original del manifiesto objeto de las bases de
datos (véase la primera columna lateral, "Orígenes de la base de datos
de objetos"), declaró que una consulta era una instalación
característica de un objeto base de datos, y la ODMG normas definen un
alto nivel de lenguaje de consultas, OQL. La naturaleza del modelo de
datos dicta que la base de datos objeto de consultas se expresó un
tanto diferente a las consultas SQL, haciendo uso del objeto más que se
suma a las referencias.
Integridad referencial
Garantiza la integridad referencial, por ejemplo, que usted no podría crear un orden en la base de datos para un cliente que no existe en la base de datos.
En el modelo relacional, la integridad referencial es implementada por claves foráneas de relaciones. Un ejemplo, la tabla PEDIDOS tendría una clave foránea que se refiere a la clave primaria de la tabla CLIENTES. Antes de que una nueva orden, se añada a una PEDIDOS a la tabla, la clave foránea se comprueba sobre el terreno para asegurarse de que existe una concordancia con respecto al valor en la tabla CLIENTES.
En el modelo de objetos, la integridad es controlada por la aplicación. Objeto referencias creadas en la solicitud se mantienen en la base de datos. En el ejemplo, si la aplicación está escrita de forma que todos los nuevos casos Orden se crean como campos de los objetos del cliente, entonces no es posible tener un objeto huérfanos Orden. La base de datos coincide con la lógica de la aplicación lógica.
La forma en que anteriormente las características de trabajo, depende fuertemente del modelo de datos. Las siguientes características son también necesarios para una base de datos que se considera ACID (Atomicidad, Concurrencia, Aislamiento y Durabilidad) propiedades. En la medida de lo que el usuario o desarrollador se refiere, la forma en que se utiliza depende no de lo que el modelo de datos de la base de datos está utilizando, pero sobre la base de datos de productos.
Hemos visto "a vuelo de pajaro" la evolución de los modelos de datos y una breve comparación de los modelos de objetos y modelos relacionales.
Recursos utilizados
http://es.wikipedia.org/wiki/Base_de_datos
http://www.db4o.com/espanol/
Libro:
The Definitive Guide to db4o
Espero que hallá sido de su agrado y gracias por no dormirse….