PDF de programación - Tema 3 - Modelado relacional

26/03/2012

1

http://en.wikipedia.org/wiki/Edgar_F._Codd

Codd estableció los fundamentos del modelo relacional en el artículos de
1970 "A Relational Model of Data for Large Shared Data Banks". En
adelante, sus publicaciones van ampliando el modelo. Colaborador de
aquellos tiempos es Chris Date, del que nos nutrimos en las referencias
bibliográficas de la asignatura. Los dos trabajaban para IBM.


2

¿Y qué es el modelo relacional?



Una forma de ver los datos, como tablas con filas y columnas (el sistema ya se
encarga de almacenar los datos como buenamente pueda, no te preocupes), y que
te muestra esos datos, simplemente, preguntando por lo que quieres saber...
aunque todo termine en ficheros en un disco duro.



Lo cierto es que esta visión de alto nivel nos oculta, precisamente, los detalles del
almacenamiento de datos a bajo nivel (sistema operativo, disco duro,
organización y acceso), al tiempo que proporciona una estructura simple basada
en conceptos matemáticos harto conocidos que da coherencia al modelo en sí. Un
detalle importante es que Codd da la impresión de querer alejarse todo lo posible
de los entornos de programación ofreciendo un método simple e intuitivo de
tratar la información. Por eso, desde el punto de vista del usuario normal, la
ausencia de punteros o herramientas similares que relacionen datos dispersos,
sustituidos por simples comparaciones de valores.



3

El aspecto final, la percepción que tenemos del almacenamiento de los datos,
aunque vamos a ver que es más complejo que eso, es el de una tabla con filas y
columnas. Las columnas, al igual que cualquier tabla con cualquier propósito,
indican una aspecto concreto, una característica de la clase de objeto que se está
representando. Son sus atributos, las características que lo definen dentro de
nuestro sistema de información. Son también, como veremos, las componentes de
un esquema de tupla, siendo las tuplas el equivalente formal de lo que
entendemos por fila. Cada tupla representa a un individuo, un caso, un ejemplo,
un objeto que pertenece a la clase de objetos.



En la terminología del paradigma orientado a objeto, la clase de objetos define al
objeto, y los objetos son los casos concretos, los elementos que pertenecen o se
definen por esa clase de objetos.

4

El gran acierto del modelo relacional, y casi seguro el objetivo de Codd al
definirlo, es la aparición de un lenguaje que se aparta de los programadores para
acercarse a los usuarios con conocimientos mínimos (salvando distancias, claro,
no deja de ser un lenguaje que puede llegar a resultar compleja). El Standard
Query Language es un leguaje de definición y manipulación de datos de
especificación, no se programa el "cómo" recuperar los datos sino que se
explicita el "qué" se quiere conseguir.



Es un lenguaje cerrado, esto es, opera con, y obtiene, tablas.

5

Antes del modelo relacional, lo más utilizado en grandes volúmenes de datos era
sistemas de ficheros sofisticados basados en topologías fácilmente reconocibles
pero, también, difíciles de manejar y comprender. De hecho, el mantenimiento de
los datos era tarea exclusiva de programadores, llegándose a la situación de que
el más mínimo listado debía ser solicitado puesto que se tenía que programar el
código que recorriera la estructura de la forma concreta que exigía un
determinada lista de datos ordenada y filtrada por ciertos criterios.



El modelo jerárquico estructura los datos en forma de árboles, conectando los
registros intermedios y los de hoja mediante punteros. Su capacidad de
representación estaba limitada prácticamente a relaciones 1:N, siendo
complicado llegar a simular relaciones N:M. El modelo en red (CODASYL, por
el comité encargado de definirlo) pretendía superar al jerárquico mediante una
estructura menos rígida pero también más difícil de mantener.

6

La "relación" es la estructura, única, del modelo relacional. Para entendernos, la
"relación" es lo mismo que la tabla (hablando informalmente). En cualquier caso,
tal y como establecimos en el tema Modelos de Datos, las estructuras son las
"palabras" de estos lenguajes peculiares.



Entiéndase que este es un símil muy forzado. En realidad estamos hablando de
una estructura vacía que tenemos que "rellenar" con aquello que consideremos
conveniente, y no podemos hacerlo de cualquier manera sino siguiendo ciertas
reglas: toda tabla ha de tener al menos una columna, esa columna debe trabajar
con un cierto conjunto de datos posibles, debe tener al menos una clave primaria,
para relacionarla con otras tablas se definen claves ajenas, etc., hasta llegar a la
representación completa de nuestro sistema de información. Y no dará lo mismo
poner una clave ajena en una u otra tabla, hacerlo daría como resultado sistemas
de información distintos.

7

Un dominio es un conjunto de valores escalares. Por valor escalar entendemos un
valor simple, sin estructura interna. El nombre de una calle es un dato escalar, la
dirección completa (calle, número, código postal, etc.) es un dato complejo.



Se puede operar con varios dominios mediante un producto cartesiano. El
producto cartesiano obtiene un conjunto de tuplas; las tuplas tienen tantas
componentes como dominios se han utilizado en el producto, y estas
componentes ocupan un orden determinado. El resultado final es la combinación
de todos los valores de cada dominio con todos los valores de los otros dominios.



Se define la relación matemática como el subconjunto de un producto cartesiano
de n dominios.

8

Dos métricas simples se asocian a la relación matemática: el grado, la cantidad
de dominios que definen el producto cartesiano, y por ende la relación, y la
cardinalidad, que es la cantidad de tuplas que conforman la propia relación.



Hablando en términos de filas y columnas, el grado es la cantidad de columnas
de la tabla y la cardinalidad la de filas. El grado es constante (salvo que se
redefina la relación) mientras que la cardinalidad es variable, depende de en qué
momento examinemos la relación habrá más o menos tuplas (habremos insertado
o borrado).



Hacemos notar que el término "cardinalidad" aquí tiene un sentido diferente al de
las "cardinalidades" que hemos venido usando para concretar las relaciones 1:1,
1:N, N:M, etc. (aunque, en el fondo, están relacionados). Igualmente, "relación"
como relación matemática (como "tabla") es un sentido diferente al de "relación"
como asociación entre clases de objetos (entidades o tablas).

9

Aquí tenemos un ejemplo de una relación definida a partir del producto
cartesiano de 2 dominios. Como vemos, en dos instantes consecutivos, el grado
se mantiene constante mientras que la cardinalidad cambia.

10

En todo caso, hemos y estamos hablando de conjuntos
(http://es.wikipedia.org/wiki/Conjunto). El resultado de un producto cartesiano es
un conjunto de tuplas. Las tuplas son listas de componentes. La relación es un
subconjunto.



Como tales, tienen unas propiedades particulares que Codd iba buscando como
base para definir su modelo relacional.

11

A pesar de lo elegante del formalismo matemático elegido para definir el modelo
de datos, no es cómodo acceder a las componentes de la tupla por su orden, debo
saber que donde yo estoy almacenando el nombre de los alumnos es la tercera
componente de cada tupla. Si le damos nombre a las componentes nos evitamos
recurrir a esta ordenación al tiempo que nos resulta más fácil recordar cómo
recuperar los datos necesarios.



12

Este "dar nombre a las componentes de las tuplas de una relación" se define
como se muestra aquí:



1) el esquema de la relación (la intensión, la cabecera) es un conjunto de pares

(nombre, dominio), de nombres (o etiquetas) y dominios asociados a cada
nombre.

2) el contenido de la relación (la extensión, el cuerpo) es un conjunto de listas

de pares (nombre,valor).

13

Ahora nos da igual el orden de las componentes, alumno se define a partir de exp,
dni y nombre, cada componente "trabajando" sobre unos conjuntos de valores
determinados (domE, domD y domN).



La extensión de la relación, en un momento dado, contendrá m tuplas, y cada
tupla será n pares (nombre, valor), y no necesariamente presentaremos todas y
cada una de las tuplas con el mismo orden de componentes puesto que está
perfectamente definido con qué dato específico estamos trabajando en todo
momento.

14

Esta adaptación se traduce en que ya no necesitamos el orden de las componentes
(el orden de las columnas). No obstante (y SQL hace uso de ello, por ejemplo ...
order by 1 es ordenar por la primera columna), sí se mantiene el orden para
ciertas operaciones, como se verá en álgebra relacional. Podemos decir que es
una opción: podemos utilizar este orden o no, según nos convenga.



15

16

Al final del desarrollo matemático, de alguna forma hemos de trasladar esas
intenciones a un producto en funcionamiento. Basándose en la relación
matemática, se crean los siguientes conceptos que, finalmente, darán forma al
modelo. Todos ellos están viéndose de manera más o menos informal en la
segunda hora de las sesiones de teoría.



El modelo relacional se implementa con algo parecido a los registros. Solo con
los registros no puedo asegurar que no haya dos iguales, los ficheros no
restringen su contenido al exacto producto cartesiano. ¿Cómo conseguir que esta
estructura tan simple y típica de ficheros se comporte como un conjunto?:
definiendo el concepto de clave candidata y obligando a que siempre se defina
para toda relación. Ahora bien, para ser clave candidata no podemos permitir que
admita nulos en ninguno de sus atributos. Recordemos que NULO significa que
no sabemos qué valor tiene y, si no lo sabemos, podría ser un duplicado y ya no
cumpliría con su función.



¿Y cómo facilitamos la estructuración de los datos y sus relaciones? C