Apuntes de oposiciones: el modelo relacional

Seguimos con la serie de post sobre apuntes de oposiciones. En este caso dedicamos una entrada al modelo de datos relacional.

El modelo de datos relacional.

Las bases de datos relacionales se han ido imponiendo a lo largo de la década de los 80 debido a la universal aceptación de la superioridad que ofrece el modelo de datos en el que se basan, el modelo relacional, frente a sus antecesores: modelo jerárquico (estructuras en árbol) y modelo Codasyl (estructuras en red).
Un sistema de base de datos relacional (BDR) se caracteriza por presentar sus datos externamente como tablas, aunque internamente se sigan manejando éstos de forma convencional, por medio de índices, páginas, etc. Otra de sus características es la disponibilidad de un lenguaje para operar con estas tablas, con funciones, al menos de recuperación y modificación.

Evolución histórica del modelo relacional.

Edgar F. (Ted) Codd, un matemático formado en Oxford, que había entrado en IBM en 1949, no estaba satisfecho ni con los productos Codasyl, ni con los sistemas jerárquicos de la propia IBM por los que empezó a trabajar en una serie de informes técnicos acerca de una manera ‘nueva’ de organizar y acceder a los datos. A partir de estos trabajos publicó el artículo “A Relational Model of Data for Large Shared Data Banks” en 1970. 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.
Las relaciones se definen como conjuntos de tuplas, 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. Además, aunque no es un aspecto intrínseco del modelo relacional, según la propuesta de Codd, el usuario de un sistema relacional no tenía que preocuparse de la estructura de almacenamiento, sólo debía preocuparse por el qué consultar y no el cómo.
Hoy en día es válido todavía el resumen de su artículo [Codd 1970], especialmente la siguiente parte:
“Future users of large data banks must be protected from having to know how the data is organized in the machine (the internal representation). […] Activities of users at terminals and most application programs should remain unaffected when the internal representation of data is changed and even when some aspects of the external representation are changed. Changes in data representation will often be needed as a result of changes in query, update, and report traffic and natural growth in the types of stored information.”
Además, las consultas podían expresarse en un lenguaje de muy alto nivel, lo que incrementaba en gran medida la eficiencia de los programadores sobre bases de datos. En resumen, Codd concibió un sistema donde el usuario sería capaz de acceder a la información con comandos parecidos al lenguaje natural y donde la información estuviera almacenada en ‘tablas’. Pese a sus virtudes, la aceptación del modelo relacional no fue inmediata debido en parte a la naturaleza técnica del artículo y a su base matemática que, aunque muy simple, no era común para la industria de bases de datos de la época. Además, se dudaba de la eficiencia del modelo. Más aún, dentro de IBM,
la reticencia fue muy grande, ya que IBM había invertido una gran cantidad de esfuerzo y dinero en el producto ya existente IMS y líder del mercado. La nueva tecnología relacional debía demostrar que era mucho mejor que la existente para cambiar la situación.
De hecho, Codd publicó el artículo en una revista de ámbito científico y abierto porque nadie en IBM (ni siquiera él mismo) reconoció en su momento el impacto que tendría después. Todos se sorprendieron pronto de que la respuesta externa al artículo fuera muy positiva. Incluso se acogió la idea con todo su potencial comercial. La reacción inicial de IBM fue tajante: declaró IMS su producto estratégico con exclusividad y consideró el modelo relacional como contrario a sus intereses.
Codd, por su parte, no cedió en su defensa pública de las ventajas de su propuesta e incluso mantuvo un debate público con Charles Bachman, el mayor defensor del estándar Codasyl, ignorando del debate al modelo jerárquico, en el cual se basaba el IMS. Esto dejaba al modelo jerárquico del IMS en una situación incómoda.
Afortunadamente, y en parte debido a esta publicidad, desde fuera, la Universidad de California en Berkeley creyó en la idea del modelo relacional y obtuvo financiación militar y de la NSF (National Science Foundation) para desarrollar un sistema relacional, el Ingres. Otros proyectos de SGBD basados en el modelo de datos relacional que aparecieron por la misma época fueron:

• System R de IBM (1974-1977)
• System 2000 de la Universidad de Austin en Texas
• El proyecto Sócrates de la Universidad de Grenoble en Francia
• ADABAS de la Universidad técnica de Darmstadt en Alemania.

Posteriormente a los prototipos aparecieron numerosos sistemas relacionales comerciales, tales como: INGRES
de RTI (1980), SQL/DS de IBM (1981), ORACLE de RSI (1981), DB2 de IBM (1983), RDB de DIGITAL (1983),
etc.
En la década de los 80 se desarrolla SQL Server en Sybase para sistemas UNIX y posteriormente se transportó a
sistemas Windows NT. Desde 1994 Microsoft ha lanzado nuevas versiones de este producto de bases de datos
independientemente de Sybase, que dejo de usar el nombre SQL Server a finales de los 90.
Codd Introdujo la teoría matemática de las relaciones de el campo de las bases de datos, lo que supuso un sólido fundamento teórico para el desarrollo, dentro del enfoque relacional de los nuevos sistemas. El modelo que CODD propone en su documento esta basado en la teoría de las relaciones en donde los datos se estructuran lógicamente en forma de relaciones o tablas, siendo objetivo fundamental la independencia de la estructura lógica respecto al almacenamiento y otras características físicas. (independencia de ordenación, independencia de indización e independencia de los caminos de acceso)
El modelo relacional constituye la segunda generación de los sistemas de bases de datos. Hoy en día, existen cientos de SGBD relacionales, tanto para ordenadores personales como para sistemas multiusuario, aunque muchos no son completamente fieles al modelo relacional. El modelo relacional también tiene sus fallos, siendo uno de ellos su limitada capacidad para modelar los datos. En 1976, Chen presentó el modelo entidad-relación, que es la técnica más utilizada en el diseño de bases de datos. En 1979, Codd intentó subsanar algunas de las deficiencias de su modelo relacional con una versión extendida denominada RM/T (1979) y posteriormente RM/V2 (1990).
Durante este periodo se desarrollaron diversos lenguajes de consulta: SQUARE, SEQUEL (SQL), QBE y QUEL. De fundamental importancia es el lenguaje SQL, que fue el resultado de la convergencia de muchos de los prototipos desarrollados en la época. El trabajo de investigación en IBM conducido por Ted (E.F.) Codd, Raymond Boyce y Don Chamberlin y el trabajo en la Universidad de Berkeley conducido por Michael Stonebraker, dieron como resultado SQL.
Se estandarizó por primera vez en 1986 por el comité ANSI X3H2 como estándar de ANSI, que fue denominado SQL-86. ANSI publicó un estándar extendido en 1989, SQL-89. La siguiente versión del estándar fue SQL-92 y la más reciente SQL-99. Ya la primera estandarización de SQL, provocó la desaparición de su más inmediato competidor, QUEL. Sin embargo, QBE(Query By Example) ha sobrevivido hasta nuestros días gracias a las interfaces de usuario amigables y porque supone un primer contacto más intuitivo y rápido con las bases de datos relaciónales.

Principales características del modelo de datos relacional.

Los objetivos de este modelo son:

• Independencia física: el modo en el que se almacenan los datos no influyen en su manipulación lógica.
• Independencia lógica: la modificación de cualquier elemento de la base de datos no debe influir en los programas y/o usuarios que accede a subconjuntos parciales de los mismos.
• Flexibilidad: de forma que ofrezca a cada usuario los datos de la forma mas adecuada a la correspondiente aplicación
• Uniformidad: Las estructuras lógicas de los datos presentan un aspecto uniforma tablas, lo que facialita la concepción y manipulación.
• Sencillez: El modelo debe resultar fácil de comprender y utilizar por parte del usuario.

Estructuralmente, el elemento básico del modelo relacional es la relación y se representa en forma de tabla. Las tablas están formadas por:

• Atributos: Conjunto de columnas que representan las propiedades de las tablas.
• Tuplas: Conjunto de filas que contienes los valores de cada uno de los atributos para cada elemento de la relación.
• El dominio serian el conjunto de calores homogéneos y atómicos caracterizado por un nombre donde los atributos pueden tomar sus valores. Los dominios pueden definirse por intención o por extensión.
• Dominio compuesto combinación de dominios simples a la que se pueden aplicar ciertas restricciones de integridad por ejemplo. Existen también atributos compuestos
• Grado: Número de atributos.
• Cardinalidad : número de tuplas.
• La definición formal de relación definida sobre n dominios, no necesariamente distintos, es un subconjunto del producto cartesiano de esos dominios, donde cada elemento de la relación tupla es una serie de valores ordenados. Las clases de relación se pueden dividirse en nominadas y sin nombre:
  • Las nominadas pueden ser:
    • Persistentes: Son las relaciones cuya definición permanece en la base de datos, borrándose solamente por una acción explicita de un usuario. A su vez se dividen en:
      • Relaciones de base: Existen por si mismas y no en función de otras relaciones, Se crean explícitamente su esquema de relación y sin extensiones y definición
      • Vistas: Son relaciones derivadas que se definen dando nombre a una expresión de consulta. Son relaciones virtuales.
      • Instantáneas. Son relaciones derivadas al igual que las vistas pero con datos propios almacenados, que son resultado de ejecutar la consulta especificada o de guardar una relación base. No se actualizan cada bez que cambian los datos pero se refrescan cada cierto tiempo.
    • Temporales: desaparecen de la base de datos en un cierto tímelo sin una acción especifica del usuario.
  • Relaciones sin nombre: son los resultados de las consultas que no se materializan sino que se entregan al usuario que ha realizado la consulta, y pueden ser tanta resultados intermedios como finales. Son siempre relaciones temporales

Además de las tuplas, el modelo define claves:

• Una clave candidata de una relación es un conjunto de atributos que identifican unívoca y minimamente cada tupla. En toda relación siempre hay al menos una clave candidata, pueden tener mas de una las cuales se deben distinguir:
  • Clave primaria: Identifica a las tuplas de la relación, la escoge el usuario por consideraciones ajenas al modelo relacional
  • El resto de las claves candidatos que no se han elegido como clave primaria se llaman Clave alternativas.
  • Clave ajena de una relación R2 es un conjunto no vacio de atributos cuyos valores han de coincidir con los valores de la clave de candidata o primaria de una relación R1. R1 y R2 no son necesariamente distintas.

El modelo distingue dos tipos de restricciones: inherentes y semánticas.

Restricciones inherentes.

• No hay dos tuplas iguales, por lo que se deduce la obligatoriedad de la clave.
• La orden de las tuplas no es significativo
• El orden de los atributos no es significativo.
• Cada atributo sólo puede tomar un único valor del dominio sobre el que está definido, no admitiéndose los grupos repetitivos. Entonces se dice que la tabla que cumple esta condición normalizada(1ª forma normal)
• Regla de integridad de entidad: Ningún atributo que forme parte de la clave primaria de una relación puede tomar un valor nulo.

Restricciones semánticas.

Las principales son las siguientes:

• Clave primaria: Permite declara a uin atributo p conjunto de atributos como clave primaria de una relación, por los que su calores no se pueden repetir ni se nulos
• Unicidad
• Obligatoriedad
• Integridad referencial

El modelo relacional, al igual que el resto de modelos, permite realizar las siguientes funciones desde un punto de vista dinámico:

• Inserción de tuplas.
• Borrado de tuplas.
• Modificación de tuplas.
• Consultas.

Condiciones de CODD para que un SGBD sea considerado relacional.

Codd estableció en 1985 doce principios, de los cuales al menos seis deben satisfacerse para que una base de datos (BD) pueda considerarse totalmente relacional.
Estos fueron precedidos de una regla general global, llamada "Regla Cero". Estos principios pueden resumiese de la
siguiente forma:

• Regla 0: Gestión de una BDR. Un sistema de gestión de base de datos relacional (SGBDR), debe ser capaz de manejar la BD exclusivamente con sus capacidades relacionales.
• Regla 1: Representación de la información. Toda la información en una BDR se representa explícitamente a nivel lógico y de una manera única, por medio de valores en tablas.
• Regla 2: Acceso garantizado. Todos y cada uno de los datos elementales en una BDR, deben ser accesibles lógicamente mediante el recurso a una combinación de: nombre de tabla, valor de clave primaria y nombre de columna.
• Regla 3: Representación sistemática de la información que falta. Los valores nulos deben ser soportados por un sistema de gestión de BD (SGBD) completamente relacional para representar, de modo sistemático, la información desconocida o inaplicable.
• Regla 4: Catálogo dinámico. La descripción de la BD se representa, a nivel lógico, en la misma forma que los datos ordinarios, de modo que los usuarios autorizados puedan aplicar el mismo lenguaje relacional para consultarlo.
• Regla 5: Sublenguaje global de datos. Debe existir, al menos, un lenguaje cuyas sentencias sean expresabas por medio de una sintaxis bien definida, como cadena de caracteres, y capaz de soportar definición de datos, definición de vistas, manipulación de datos, restricciones de integridad, autorizaciones y manejo de transacciones.
• Regla 6: Actualización de vistas. Todas las vistas teóricamente actualizables deberán ser también actualizables por el sistema.
• Regla 7: Inserciones, actualizaciones y eliminaciones de alto nivel. La capacidad para manejar, como un solo operando, la relación base o una relación derivada se aplica no sólo a las recuperaciones de datos, sino también, a sus inserciones, actualizaciones y eliminaciones.
• Regla 8: Independencia física de los datos. Los programas de aplicaciones y las actividades terminales permanecerán lógicamente inalterados siempre que se realicen cambios en las representaciones de almacenamiento o en los métodos de acceso.
• Regla 9: Independencia lógica de los datos. Cuando se efectúe en las tablas cualquier tipo de cambio que preserve la información, los programas de aplicación permanecerán intactos.
• Regla 10: Independencia de la integridad. Las reglas de integridad de una BD particular deben ser definibles por medio del sublenguaje de datos relacional y almacenadas en el catálogo, no en los programas de aplicaciones.
• Regla 11: Independencia de la distribución. Un sistema relacional debe tener un sublenguaje de datos que pueda soportar bases de datos distribuidas (BDD) sin alterar los programas de aplicaciones o actividades finales.
• Regla 12: Regla de la no inversión. Si un sistema relacional tiene un lenguaje de bajo nivel, éste no puede ser utilizado para pasar por alto las reglas de integridad y las restricciones expresadas por medio del lenguaje relacional de más alto nivel.

Fundamentos matemáticos del modelo de datos relacional: Algebra Relacional y Cálculo Relacional.

El modelo relacional es el modelo lógico en el que se basan la mayoría de los SGBD comerciales en uso hoy en día. En primer lugar, se trata la descripción de los principios básicos del modelo relacional: la estructura de datos relacional y las reglas de integridad.
A continuación, se presenta un tratamiento detallado del álgebra relacional, que es un conjunto de operaciones para manipular la estructura de datos relacional y especificar consultas de datos.
El álgebra relacional es un lenguaje procedural, mientras que el cálculo relacional es un lenguaje equivalente no procedural.
El modelo relacional se basa en dos ramas de las matemáticas: la teoría de conjuntos y la lógica de predicados de primer orden. El hecho de que el modelo relacional esté basado en la teoría de las matemáticas es lo que lo hace tan seguro y robusto. Al mismo tiempo, estas ramas de las matemáticas proporcionan los elementos básicos necesarios para crear una base de datos relacional con una buena estructura, y proporcionan las líneas que se utilizan para formular buenas metodologías de diseño.
Hay quien ofrece una cierta resistencia a estudiar complicados conceptos matemáticos para tan sólo llevar a cabo una tarea bastante concreta. Es habitual escuchar quejas sobre que las teorías matemáticas en las que se basa el modelo relacional y sus metodologías de diseño, no tienen relevancia en el mundo real o que no son prácticas. No es cierto: las matemáticas son básicas en el modelo relacional. Pero, por fortuna, no hay que aprender teoría de conjuntos o lógica de predicados de primer orden para utilizar el modelo relacional. Sería como decir que hay que saber todos los detalles de la aerodinámica para poder conducir un automóvil. Las teorías de la aerodinámica ayudan a entender cómo un automóvil puede ahorrar combustible, pero desde luego no son necesarias para manejarlo.
La teoría matemática proporciona la base para el modelo relacional y, por lo tanto, hace que el modelo sea predecible, fiable y seguro. La teoría describe los elementos básicos que se utilizan para crear una base de datos relacional y proporciona las líneas a seguir para construirla. El organizar estos elementos para conseguir el resultado deseado es lo que se denomina diseño.

Si te ha gustado esta entrada, suscríbete para recibir las próximas entradas por correo electrónico. Por favor, apoya este blog.