Origen y

Características

Base de Datos I

1
Introducción al modelo relacional
Origen del Modelo Relacional y sus Características

El almacenamiento de los datos previamente a la creación de de las Bases de datos

había sido reservado para que fuera realizado en archivos en los que se
almacenaban toda la información separados en campos y registros.

Los primeros archivos guardaban estos registros ordenados de acuerdo a un criterio

dado y si era necesario otro orden se le aplicaba un proceso especial que derivaba
en otro archivo ordenado por el criterio elegidos. Luego, los programas
comenzaban a leer en forma secuencial, fila a fila, para procesar la información en
busca de listas de sueldos, modificación de saldos de cuentas bancarias, cálculos de
existencias en grandes almacenes. Esta forma de trabajo, dejaba libertad al
programador para que organizara los datos como quisiera, y resolviera eficazmente
el problema foco de su sistema. No había una visión integral de la problemática de
la empresa, si otra área necesitaba alguna de esta información, más otra de otro
aspecto, usualmente ser repetían estos datos tantas veces como fuera necesario.
Esto sucedía en los años 60 y los computadores contaban con muy poca memoria
real y el almacenamiento en medios magnéticos era en cintas y en los dispositivos
de acceso directo que mejoraban el tiempo de acceso a los registros sobre la forma
secuencial nombrada.

El medio estaba próximo a vivir un cambio dado por un Matemático Ingles, Edgar
Codd, ex piloto de la Real Fuerza Aérea durante la Segunda Guerra Mundial, que
emigró a EEUU, para trabajar como Investigador en IBM. En los años 70 publica un
paper que logró la adhesión de otros expertos porque facilitaba un camino,
respaldado en la teoría de conjuntos, para resolver el problema de grandes bases
de datos compartidas. Dicho paper, publicado en Junio de 1970, se llamó “A
Relational Model of Data for Large Shared Data Banks”, algo así como Un modelo
de datos relacional para grandes bancos de datos compartidos.

Así es que el enfoque usado con los archivos, con las sentencias del lenguaje usado,
como COBOL, C, u otro generaba eficacia por un lado e ineficiencias, como la
REDUNDANCIA, cuya definición es importante destacar, según la Real Academia
Española:

“Redundancia: Cierta repetición de la información contenida en un

mensaje, que permite, a pesar de la pérdida de una parte de este,
reconstruir su contenido” (RAE, 2009)

2
Otra definición que nos acerca a la aplicación en este contexto…

“Redundancia es Repetir el registro de un hecho en distintas tablas”

Para entender que esto es un problema, se debe hacer el siguiente ejercicio mental:
si se guarda en varios registros el domicilio de un cliente, se puede afirmar que será
más fácil de acceder por que tengo una copia de esa información “a mano”. Pero
este acceso fácil enseguida muestra desventajas: si el cliente cambia de domicilio,
se tendrá que buscar todas las repeticiones para modificarlas, de otro modo, si no
se actualizan TODAS las repeticiones de este domicilio, repetido en el modelo de
datos general de la empresa, estaremos provocando inconsistencia, lo que hará
perder confianza en la información almacenada, ya que cuando consulto en un
lugar, me devuelve una dirección y si consulto en otro, me figura una diferente,
¿Cuál de las dos es la correcta? Este problema genera procesos extra de validación
y en el peor de los casos se produce la pérdida de la confianza y pese a tener un
sistema informático, se recurre a alternativas menos eficientes, por esta falta de
confianza.

Extractando un importante trabajo publicado en Internet, encontramos que al

hablar de la situación en los orígenes del Modelo Relacional:

“El simple enfoque de abrir un archivo de datos, rápidamente se convirtió en

problemático, con muchas necesidades a solucionar. Los proveedores informáticos
tuvieron que soportar las necesidades críticas de un mercado creciente en evolución,
sobre sus necesidades de procesamiento de datos.

El primer sistema de Administración de Base de datos (DBMS, por el título Data Base
Management System) aparece durante los años 60 en un momento en que los
proyectos tenían una escala significativa, y éstos eran estudiados, planificados por
los ingenieros. Nunca antes tales grandes grupos de datos habían sido grabados en
esta nueva tecnología. Los problemas iniciales y sus soluciones fueron identificados,
a veces en Tiempo Real, es decir, cuando aparecían eran estudiados y solucionados.

Los DBMS se hicieron necesarios debido a que los datos eran más volátiles de lo
planeado y por que había cada vez más limitaciones en los costos asociados a los
medios de almacenamiento de datos. Los datos crecieron como una colección, y esto
hizo necesario administrarlos en cada una de las transacciones realizadas. En los
años 70 cada proveedor de sistemas de hardware lo suficientemente capaz de
soportar las necesidades demandantes de los clientes, incorporaban sus propios
sistemas DBMS.

3
Los primeros eran específicos de cada uno de los proveedores. IBM lideraba el
campo, pero había un gran número de competidores que ofrecían soluciones de
Sistemas de almacenamiento de Registros.

En estos años los problemas de almacenamiento, acceso y de respaldo entre otras

tareas de mantenimiento, como reorganización y re-indexado de los datos, eran
tareas llevadas a cabo a través de proceso iniciados por operadores humanos para
mantener accesos veloces de acuerdo a la necesidad de las aplicaciones.”
(Brown,2002)

Codd propuso que los sistemas de bases de datos deberían presentarse a los
usuarios con una visión de los datos organizados en estructuras llamadas relaciones
(tablas), definidas como conjuntos de tuplas (filas) y no como series o secuencias
de objetos, con lo que el orden no es importante. Por tanto, detrás de una relación
puede haber cualquier estructura de datos compleja que permita una respuesta
rápida a una variedad de consultas. Codd hizo entonces énfasis en que el usuario
de un sistema relacional sólo debía preocuparse por el qué consultar y no el cómo
de las estructuras de almacenamiento (lo que ahora se conoce como modelo físico).
Aún hoy se consideran validas sus afirmaciones, especialmente la siguiente:

“Los usuarios futuros de grandes bancos de datos deben ser protegidos de

tener que saber cómo están organizados los datos en la máquina (la
representación interna. (…) Las actividades de los usuarios en sus terminales
y la mayoría de programas de aplicación no debería verse afectados cuando
se cambia la representación interna de los datos o incluso cuando se
cambian algunos aspectos de la representación externa. Se necesitará
cambiar la representación de los datos a menudo como resultado de los
cambios en el tráfico de las consultas, actualizaciones e informes y como
consecuencia del crecimiento natural en los tipos de información
almacenada.” [Brown, 2002]

Puede parecer extraño, pero las ideas de Codd no fueron “recibidas con los brazos
abiertos” en IBM, donde realizaba sus labores de investigación, según afirma
Harlwood Kolsky, un físico y antiguo compañero de Codd; “fue un enfoque
revolucionario”, recuerda Kolsky. El nuevo enfoque de Codd, basado en la teoría
matemática de conjuntos, no tuvo eco inmediato en IBM, que prefirió a IMS, un
producto al que se le había invertido una fuerte cantidad de esfuerzo y dinero.
[Quiroz, 2003]

Un grupo de la Universidad de Berkeley en California, liderado por Michael

Stonebreaker, creyó en la idea del modelo relacional y obtuvo financiamiento para
desarrollar un sistema, el Ingres, cuya primera versión se presentó en 1974 y fue el
primer manejador relacional de bases de datos funcional. Esto tuvo como
consecuencia que IBM reaccionara poniendo en marcha otro sistema relacional, el

4
System R con características de multiusuario y un lenguaje de consulta
estructurado, el SEQUEL que luego pasaría a llamarse SQL (Structured Query
Language). Para entonces Larry Ellison, un empresario del Valle del Silicón, había
tomado ventajas de los escritos de Codd para crear un nuevo producto y una nueva
empresa que hasta la fecha se conoce como Oracle.

En 1985 Codd publicó sus famosas 12 reglas sobre el modelo relacional de bases de
datos, un resumen de sus características fundamentales. Es preciso resaltar que
todavía hoy algunas de estas reglas son de difícil implementación para los
fabricantes de manejadores de bases de datos relacionales. Además de ser
considerado como el padre del modelo relacional, Codd también incursionó en el
modelo multidimensional de análisis de datos conocido como OLAP (On Line
Analytical Processing) y en 1993 Codd y algunos de sus colegas publicaron las “12
reglas para OLAP”.

A lo largo de su vida, el Dr. Codd recibió innumerables reconocimientos. En 1981,

la ACM (Association for Computer Machinery), otorgó a Codd el “Premio Turing”,
considerado uno de los más prestigiosos en el campo de la informática. Muchos de
sus compañeros y seguidores han contribuido, y siguen haciéndolo, a fortalecer su
modelo el cual es, por mucho, el más utilizado actualmente como sistema de bases
de datos.

La esencia del modelo

La estructura fundamental del modelo relacional es la relación, luego conocido
simplemente como Tabla, es decir, una tabla bidimensional constituida por filas
(tuplas) y columnas (atributos). Las relaciones representan las entidades que se
consideran interesantes en la base de datos. Cada instancia de la entidad
encontrará sitio en una tupla de la relación, mientras que los atributos de la relación
representan las propiedades de la entidad. Por ejemplo, si en la base de datos se
tienen que representar personas, podrá definirse una relación llamada "Personas",
cuyos atributos describen las características de las personas. Cada tupla de la
relación "Personas" representará una persona concreta. Por ejemplo, la relación:

Personas (Documento Nacional de Identidad DNI, nombre, apellido, sexo,

estado civil, fecha nacimiento)

es apenas una definición de la estructura de la tabla, es decir, su nombre y la lista

de atributos que la componen. Si esta estructura se puebla con datos, entonces
tendremos una lista de valores individuales para cada tupla, atributo por atributo.

5
En Wikipedia encontramos la siguiente definición que permite ampliar la idea:

“En este modelo todos los datos son almacenados en relaciones, y como
cada relación es un conjunto de datos, el orden en el que estos se almacenen
no tiene mayor relevancia (a diferencia de otros modelos como el jerárquico
y el de red). Esto tiene la considerable ventaja de que es más fácil de
entender y de utilizar por un usuario no experto. La información puede ser
recuperada y mostrada por medio de «consultas» que ofrecen una amplia
flexibilidad y poder para administrar la información”. [Wiki,2009a]

Aunque una relación es más conocida como tabla, las tuplas como filas y los
atributos como columnas, en este apartado usaremos la terminología original y de
donde deriva el nombre del modelo. Las tuplas en una relación son un conjunto en
el sentido matemático del término, es decir, una colección no ordenada de
elementos diferentes.

Para distinguir una tupla de otra, se recurre al concepto de "clave primaria", o sea
un atributo o conjunto de atributos que permiten identificar unívocamente una
tupla en una relación (en el ejemplo, el atributo DNI cumple con esta función).
Naturalmente, en una relación puede haber más combinaciones de atributos que
permitan identificar unívocamente una tupla ("claves candidatas"), pero entre
éstas se elegirá una sola para utilizar como clave primaria. Los atributos de la clave
primaria no pueden asumir el valor nulo (que significa un valor no determinado),
en tanto que ya no permitirían identificar una tupla concreta en una relación.

Esta propiedad de las relaciones y de sus claves primarias se conoce como

integridad de las entidades.

Cada atributo de una relación se caracteriza por un nombre y por un dominio. El

dominio indica qué valores pueden ser asumidos por una columna de la relación. A
menudo un dominio se define a través de la declaración de un tipo para el atributo
(por ejemplo diciendo que es una cadena de diez caracteres), pero también es
posible definir dominios más complejos y precisos. Por ejemplo, para el atributo
"sexo" de nuestra relación "Personas" podemos definir un dominio por el cual los
únicos valores válidos son 'M' y 'F'; o bien para el atributo "fecha nacimiento"
podremos definir un dominio por el que se consideren válidas sólo las fechas de
nacimiento después del uno de enero de 1960, si en nuestra base de datos no está
previsto que haya personas con fecha de nacimiento anterior a esa.

6
El motor de datos se ocupará de controlar que en los atributos de las relaciones se
incluyan sólo los valores permitidos por sus dominios. Característica fundamental
de los dominios de una base de datos relacional es que sean "atómicos", es decir
que los valores contenidos en los atributos no se puedan separar en valores de
dominios más simples. Más formalmente se dice que no es posible tener atributos
con valores múltiples o multivaluados.

La normalización, es decir, la razón y uso de las formas normales, es un proceso que

persigue evitar la repetición innecesaria de datos (redundancia). Una solución a
este problema es repartirlos en varias relaciones y utilizar referencias por valor
entre ellas. Este es un ejemplo típico de que la tupla de una relación, digamos de
Empleados, no deba repetir toda la información de su departamento, sino que debe
utilizar una referencia por valor a la tupla de la relación Departamento, donde están
todos estos datos. Este procedimiento ahorra espacio de almacenamiento,
optimiza el rendimiento y, al eliminar la redundancia, impide modificaciones
parciales o incompletas que podrían dar lugar a inconsistencias. Existen hasta 6
formas normales pero, en la práctica, se adopta generalmente la tercera forma
normal.

Junto con el modelo, el Dr. Codd también propuso el álgebra relacional, un lenguaje
formal con una serie de operadores que trabajan sobre una o varias relaciones para
obtener otra relación resultado, sin que cambien las relaciones originales. Tanto los
operadores como los resultados son relaciones, por lo que la salida de una
operación puede ser la entrada de otra operación. Esto permite anidar expresiones
del álgebra del mismo modo que se pueden anidar las expresiones aritméticas.
Codd originalmente propuso ocho operadores pero sólo cinco son fundamentales:
restricción, proyección, producto cartesiano, unión y diferencia, que permiten
realizar la mayoría de las operaciones de obtención de datos. Los operadores no
fundamentales son la concatenación o reunión (join), la intersección y la división,
que se pueden expresar a partir de los cinco operadores fundamentales. La
restricción y la proyección son operaciones unarias porque operan sobre una sola
relación. El resto de las operaciones son binarias porque trabajan sobre pares de
relaciones. Ampliaremos este tema mas adelante.

Partiendo del cálculo relacional, el Dr. Codd desarrolló el primer lenguaje relacional
llamado ALPHA el cual formó el fundamento para el desarrollo subsecuente de
lenguaje SQL (original SEQUEL). Otros lenguajes relacionales de consulta, tales
como el QBE (Query By Example, consulta a través de ejemplos), se basaron en el
álgebra relacional definida por el Dr. Codd.

7
Durante las fases de desarrollo del modelo relacional, el comité ANSI/SPARC
(American National

Standard Institute - Standards Planning and Requirements Committee) de 1975 definió la

separación en tres niveles de los sistemas manejadores de bases de datos: externo,
conceptual e interno que vinieron a redundar en lo que ahora se conoce como
subesquema externo, esquema lógico y esquema físico. En otras palabras: los
modelos conceptual, lógico y físico. Sin embargo, fue el Dr. Codd quien estableció
los fundamentos para esta separación con conceptos tales como la independencia
lógica y física de los datos (reglas 8 y 9), de independencia, integridad y distribución
(reglas 10 y 11). Más adelante, en esta materia, veremos en detalle estas reglas.

Como consecuencia, el mundo de las bases de datos cambió para siempre. A partir
del modelo relacional el usuario no tendría porqué preocuparse de los aspectos
técnicos de la base de datos: simplemente sus necesidades de información se
satisfarían de acuerdo a su perspectiva de los datos.

Igualmente, los programadores de aplicaciones no tendrían que lidiar con el

modelo físico, asunto exclusivo del administrador de bases de datos (en inglés DBA)
quien, si así lo determinara conveniente y en aras de un mejor rendimiento, podría
modificar el modelo físico de datos sin afectar al modelo lógico. Como veremos,
muchos de estos conceptos fundamentales aún son confundidos o ignorados por
analistas, desarrolladores y fabricantes que aún no han entendido o podido
implementar un verdadero modelo relacional de bases de datos.

El futuro del modelo relacional

Ya desde principios de 1990 se hablaba del “fin del modelo relacional” y su
sustitución por las bases de datos orientadas a objetos. Pero el caso es que en el
año 2001 de 8 mil 884 millones de dólares pagados por licencias de bases de datos,
7 mil 107 correspondieron al modelo relacional. Más significativo es el hecho de
que en el año 2000 las ventas para bases de datos relacionales tuvieron un
incremento del 15% en tanto, para bases de datos orientadas a objetos y de otro
tipo tuvieron un incremento negativo. Hay varias razones para explicar lo anterior
que no detallaremos pero sin duda resaltan lo sencillo del modelo y su sólido
fundamento teórico. La adición de nuevas características al modelo relacional es
asunto de intenso debate así como la modernización y adecuación del lenguaje SQL
a las exigencias siempre cambiantes de un entorno de gran competencia. Sin duda
el modelo ha superado la prueba del tiempo. Los proveedores han añadido
características de “objetos” a sus productos, lo cual permite a los usuarios definir
sus propios tipos de datos. En resumen, el modelo relacional de bases de datos es
un estándar de la industria consolidado, una tecnología confiable y eficiente que
estará entre nosotros aún por muchos años antes de que sea desplazada por una

8
nueva y mejor. Se encuentran entonces Bases de Datos llamadas Objeto-Relacional,
porque permiten crear objetos con las características de la Orientación a Objetos,
como encapsulamiento, algún grado de herencia, para facilitar el desarrollo de
aplicaciones que tengan este paradigma y que no sea necesario una capa de
conversión de Relacional a Objetos.

A modo de conclusión sobre lo visto:

Las necesidades de información de los usuarios cambian constantemente. No es
posible anticiparlas en su totalidad. El modelo relacional de bases de datos con sus
relaciones normalizadas es una solución simple y elegante para satisfacer las más
diversas condiciones de consulta y extracción de datos e información.

El Dr. Codd, al recibir el premio Turing en 1981, declaró que una verdadera
base de datos relacional puede:

· Estar al alcance de los no programadores, donde antes los programadores

fueron una necesidad.

· Incrementar la productividad de los programadores en la mayoría de

aplicaciones de bases de datos.

En otro momento, hizo la siguiente reflexión:

“…es importante recordar que las bases de datos se establecen para

beneficio de los usuarios finales, y no para los programadores de
aplicaciones quienes actúan como intermediaros para las necesidades
actuales de procesamiento de datos”. (Quiróz, 2003) ¡Sabias palabras!

9
10