MODELO RELACIONAL

INTRODUCCIÓN

En los primeros años de las bases de datos, cada aplicación almacenaba datos en su propia estructura
única. Cuando los desarrolladores querían crear aplicaciones para usar esos datos, tenían que saber
mucho sobre la estructura de datos particular para encontrar los datos que necesitaban. Estas
estructuras de datos eran ineficientes, difíciles de mantener y difíciles de optimizar para ofrecer un buen
rendimiento de la aplicación.

El modelo relacional proporcionó una forma estándar de representar y consultar datos que cualquier
aplicación podría utilizar. Desde el principio, los desarrolladores reconocieron que la principal fortaleza
del modelo de base de datos relacional estaba en el uso de tablas, que eran una forma intuitiva, eficiente
y flexible de almacenar y acceder a información estructurada.

Con el tiempo, cuando los desarrolladores comenzaron a utilizar el lenguaje de consulta estructurado
(SQL) para escribir y consultar datos en una base de datos, y, derivado de esto, surgió otra fortaleza del
modelo relacional. Durante muchos años, se utilizó ampliamente el SQL como lenguaje para consultas de
bases de datos. El SQL, que se basa en el álgebra relacional, proporciona un lenguaje matemático
internamente consistente que facilita la mejora del rendimiento de todas las consultas de la base de datos.
En comparación, otros enfoques deben definir consultas individuales.

El modelo relacional, para el modelado y la gestión de bases de datos, es un modelo de datos basado en
la lógica de predicados y en la teoría de conjuntos.

Edgar Frank Codd definió las bases del modelo relacional a finales de los 60’s. Trabajaba para IBM,
empresa que tardó un poco en implementar sus bases. Pocos años después el modelo se empezó a
implementar cada vez más, hasta ser el modelo de bases de datos más popular.

CONCEPTO

Es un modelo que se basa en el concepto matemático de relación, que gráficamente se representa

mediante una tabla. Es decir, una relación es una tabla, con columnas y filas. Un SGBD sólo necesita que
el usuario pueda percibir la base de datos como un conjunto de tablas.

Frecuentemente, una relación se conceptualiza de una manera más fácil de imaginar, esto es, pensando
en cada relación como si fuese una tabla que está compuesta por registros (cada fila de la tabla sería un
registro o tupla), y columnas (también llamadas campos).

Página No. I
OBJETIVOS DEL MODELO RELACIONAL

En las bases de Codd se definían los objetivos de este modelo:

▪ Independencia física: La forma de almacenar los datos no debe influir en su manipulación. Si el

almacenamiento físico cambia, los usuarios que acceden a esos datos no tienen que modificar sus
aplicaciones.
▪ Independencia lógica: Las aplicaciones que utilizan la base de datos no deben ser modificadas por
que se inserten, actualicen y eliminen datos.
▪ Flexibilidad: La base de datos ofrece fácilmente distintas vistas en función de los usuarios y
aplicaciones.
▪ Uniformidad: Las estructuras lógicas de los datos siempre tienen una única forma conceptual (las
tablas), lo que facilita la creación y manipulación de la base de datos por parte de los usuarios.
▪ Sencillez: Las características anteriores hacen que este Modelo sea fácil de comprender y de
utilizar por parte del usuario final.

TÉRMINOS FORMALES DEL MODELO RELACIONAL.

Existen una serie de términos formales que se corresponden con expresiones informales. Conviene
conocerlos para así familiarizarse con ellos. En la práctica suelen usarse las expresiones sencillas, más
fáciles de entender.

• Relación: Tabla bidimensional para la representación de datos.

• Tuplas: Filas de una relación que contiene valores para cada uno de los atributos (equivale a
los registros). Representa un objeto único de datos implícitamente estructurados en una tabla.
Un registro es un conjunto de campos que contienen los datos que pertenecen a una misma
entidad.
• Atributos: Columnas de una relación y describe las características particulares de cada campo.
• Esquemas: Forma de representar una relación y su conjunto de atributos.
• Claves: Campo cuyo valor es único para cada registro. Principal, identifica una tabla, y Foránea,
clave principal de otra tabla relacionada.
• Clave Primaria: identificador único de una tupla.
• Cardinalidad: número de tuplas(m).
• Grado: número de atributos(n).
• Dominio: colección de valores de los cuales el atributo obtiene su atributo.

Ejemplo de representación del modelo relacional y sus términos formales:

Página No. II
CARACTERÍSTICAS

• Los datos son atómicos o monovaluados.

• Los datos de cualquier columna son de un solo tipo.
• Cada columna posee un nombre único.
• El orden de las columnas no es de importancia para la tabla.
• Las columnas de una relación se conocen como atributos.
• Cada atributo tiene un dominio.
• No existen 2 filas en la tabla que sean idénticas.
• La información en las bases de datos es representada como datos explícitos.
• Cada relación tiene un nombre específico y diferente al resto de las relaciones.
• Los valores de los atributos son atómicos: en cada tupla, cada atributo (columna) toma un solo
valor. Se dice que las relaciones están normalizadas.
• No hay dos atributos que se llamen igual.
• El orden de los atributos no importa: los atributos no están ordenados.
• Cada tupla es distinta de las demás: no hay tuplas duplicadas
• El orden de las tuplas no importa: las tuplas no están ordenadas.
• Los atributos son atómicos: en cada tupla, cada atributo (columna) toma un solo valor. Se dice
que las relaciones están normalizadas.
• No hay dos atributos que se llamen igual.
• El orden de los atributos no importa: los atributos no están ordenados.
• Cada tupla es distinta de las demás: no hay tuplas duplicadas
• El orden de las tuplas no importa: las tuplas no están ordenadas.

¿QUÉ ES UNA BASE DE DATOS RELACIONAL?

Es una base de datos que cumple con el modelo relacional, el cual es el modelo más utilizado en la
actualidad para implementar bases de datos ya planificadas. Permiten establecer interconexiones
(relaciones) entre los datos (que están guardados en tablas), y a través de dichas conexiones
relacionar los datos de ambas tablas, de ahí proviene su nombre: "Modelo Relacional".

LAS TABLAS

Las bases de datos relacionales se basan en el uso de tablas (también se les llama relaciones). Las tablas
se representan gráficamente como una estructura rectangular formada por filas y columnas. Cada
columna almacena información sobre una propiedad determinada de la tabla (se le llama también
atributo), como por ejemplo nombre, número de control, apellidos, edad, etc. Cada fila posee una
ocurrencia o ejemplar de la instancia o relación representada por la tabla (a las filas se las llama también
tuplas).

Página No. III

TIPOS DE TABLAS

▪ Persistentes. Sólo pueden ser borradas por los usuarios:

o Base. Independientes, se crean indicando su estructura y sus ejemplares.
o Vistas. Son tablas que sólo almacenan una definición de consulta, resultado de la cual
se produce una tabla cuyos datos proceden de las bases o de otras vistas e
instantáneas. Si los datos de las tablas base cambian, los de la vista que utiliza esos
datos también cambia.
o Instantáneas. Son vistas (creadas de la misma forma) que sí que almacenan los datos
que muestra, además de la consulta que dio lugar a esa vista. Sólo modifican su
resultado (actualizan los datos) siendo refrescadas por el sistema cada cierto tiempo.
▪ Temporales. Son tablas que se eliminan automáticamente por el sistema. Pueden ser de
cualquiera de los tipos anteriores.

DOMINIOS
Los dominios suponen una gran mejora en este modelo ya que permiten especificar los posibles valores
válidos para un atributo. Cada dominio incorpora su nombre y una definición del mismo. Ejemplos de
dominio:

▪ Dirección: 50 caracteres
▪ Nacionalidad: español, francés, italiano, etc.

Los dominios pueden ser también compuestos a partir de otros (año, mes y día = fecha)

CLAVES
▪ clave candidata. Conjunto de atributos de una tabla que identifican unívocamente cada tupla de la
tabla.
▪ clave primaria. Clave candidata que se escoge como identificador de las tuplas.
▪ clave alternativa. Cualquier clave candidata que no sea primaria
▪ clave externa o secundaria. Atributo de una tabla relacionado con una clave de otra tabla.

VALORES NULOS

Los valores nulos indican contenidos de atributos que no tienen ningún valor.

Página No. IV
1 PASO DEL ESQUEMA E-R AL MODELO RELACIONAL

INTRODUCCIÓN

Para iniciar con el proceso llamado reducción a tablas, a partir de los diagramas de Entidad – Relación,
vamos a usar el primer modelo conceptual elaborado, que es la agenda que contiene la base de datos de
los alumnos del 4º. “A” de la especialidad de Ofimática.

El diagrama ER, quedó de la siguiente manera:

Para asegurar la comprensión de este proceso, lo haremos, paso a paso.

Página No. V
PASO 1. Transformaciones de entidades fuertes.

En principio, las entidades fuertes del modelo Entidad Relación son transformados al modelo relacional
siguiendo estas instrucciones:

▪ Entidades. Las entidades pasan a ser tablas

▪ Atributos. Los atributos pasan a ser columnas.
▪ Identificadores principales. Pasan a ser claves primarias
▪ Identificadores candidatos. Pasan a ser claves candidatas.

Esto hace que la transformación sea de esta forma:

En el diagrama ER de ejemplo que estamos usando, se identifican 3 entidades fuertes, que son:

1. Alumno.
2. Tutor.
3. Población.

La transformación al esquema relacional, queda de la siguiente manera:

1. ALUMNOS (n_control, nombre_alumno, apellidos, fecha_nac, genero, tel_celular, pasatiempo)

2. TUTOR (curp, nombre_tutor, tel_celular_tutor, tel_casa_tutor)
3. POBLACION (código_postal, nombre_poblacion)

Ahora, crearemos las tablas o relaciones:

Relación ALUMNOS

n_control nombre_alumno apellidos fecha_nac genero tel_celular pasatiempo

1002001 Juan Pérez López 10/02/2004 M 12121 Jugar futbol
1002002 Manuel Blas Pérez 24/05/2003 M 23233 Videojuegos
1002003 María López Blas 06/11/2004 F 34344 Leer, bailar

En esta relación se almacenarán los datos de los alumnos del grupo. Se agregaron 3 alumnos, para
facilitar su comprensión.

Relación TUTOR:

curp nombre_tutor tel_celular_tutor tel_casa_tutor

AAJY700707HOCRHE3 Mario Blas 1212121 23232323
UUJY600707MOCREE4 Mariano Pérez 242424 25252525
EEJY650707HOCRMM2 Guadalupe López 656565 78787888

Página No. VI
Relación POBLACIÓN:

codigo_postal nombre_poblacion
70980 Santa María Huatulco
70989 Santa Cruz Huatulco
70900 San Pedro Pochutla

PASO 2. Transformación de las relaciones.

La idea inicial es transformar a cada relación en una tabla en el modelo relacional. Pero hay que distinguir
según el tipo de relación.

• Relación muchos a muchos

En las relaciones muchos a muchos (dos entidades 1 a muchos), la relación se transforma en una
tabla cuyos atributos son: los atributos de la relación y las claves de las entidades relacionadas
(que pasarán a ser claves externas). La clave de la tabla la forman todas las claves externas:

Este caso aplica siempre y cuando la relación tenga al menos un atributo.

En el diagrama ER de ejemplo que estamos usando, no tenemos este tipo de cardinalidad.

• Relaciones de orden n

Las relaciones ternarias, cuaternarias y n-arias que unen más de dos relaciones, se transforman
en una tabla que contiene los atributos de la relación más los identificadores de las entidades
relacionadas. La clave la forman todas las claves externas:

Este caso no aplica para nuestro ejemplo, ya que las relaciones que tenemos son binarias.

Página No. VII

 • Relaciones uno a muchos y uno a uno.

Las relaciones binarias de tipo uno a varios, y, uno a uno, no requiere ser transformadas en una
tabla en el modelo relacional. En su lugar la tabla del lado varios (tabla relacionada) incluye como
clave externa el identificador de la entidad del lado uno, y los atributos de la relación:

Así en el dibujo, el identificador2 en la tabla Entidad1 se convierte en una clave externa. En el caso
de que el número mínimo de la relación sea de cero (puede haber ejemplares de la entidad uno
sin relacionar), se deberá permitir valores nulos en la clave externa identificador2. En otro caso
no se podrán permitir (ya que siempre habrá un valor relacionado).

En el caso de las relaciones uno a uno, ocurre lo mismo: la relación no se convierte en tabla, sino
que se coloca en una de las tablas (en principio daría igual cuál) el identificador de la entidad
relacionada como clave externa.

En el caso de que una entidad participe opcionalmente en la relación, entonces es el identificador

de ésta el que se colocará como clave externa en la tabla que representa a la otra entidad.

Para el caso de nuestro ejemplo, tenemos que se cumple la condición que se indica en el texto: la
entidad ALUMNOS tiene una relación 1 a 1 con la entidad TUTOR, y la entidad TUTOR tiene una
relación 1 a muchos con la entidad ALUMNOS. También aplica para la relación ALUMNOS (un
alumno vive en una población) y POBLACIÓN (en una población, pueden vivir uno o más alumnos).

Al ser la entidad ALUMNOS, la entidad del lado varios o muchos, se lleva la llave primaria de la
entidad POBLACIÓN, y la llave primaria de la entidad TUTOR y el atributo de la relación.

Entonces, el esquema relacional de la entidad ALUMNOS, queda de la siguiente manera:

ALUMNOS (n_control, codigo_postal, nombre_alumno, apellidos, fecha_nac, genero, tel_celular,

pasatiempo, curp, parentesco)

Y, la tabla o relación, queda así:

Las entidades POBLACIÓN Y TUTOR, quedan sin cambios.

El proceso de reducción a tablas, queda de la siguiente manera:

Página No. VIII

 Relación o tabla ALUMNOS

Relación o tabla TUTOR:

curp nombre_tutor tel_celular_tutor tel_casa_tutor

AAJY700707HOCRHE3 Mario Blas 1212121 23232323
UUJY600707MOCREE4 Mariano Pérez 242424 25252525
EEJY650707HOCRMM2 Guadalupe López 656565 78787888

Relación o tabla POBLACIÓN:

codigo_postal nombre_poblacion
70980 Santa María Huatulco
70989 Santa Cruz Huatulco
70900 San Pedro Pochutla

Página No. IX
2 NORMALIZACIÓN DEL ESQUEMA RELACIONAL

Una vez obtenido el esquema relacional resultante del modelo entidad relación que representa la base de
datos, normalmente tendremos una buena base de datos. Pero, algunas veces, debido a fallos en el diseño
o a problemas indetectables en esta fase del diseño, tendremos un esquema que puede producir una base
de datos que incorpore estos problemas:

1. Redundancia. Se llama así a los datos que se repiten continua e innecesariamente por las tablas
de las bases de datos.
2. Ambigüedades. Datos que no clarifican suficientemente el registro al que representan.
3. Pérdida de restricciones de integridad.
4. Anomalías en operaciones de modificación de datos . El hecho de que al insertar un solo elemento
haya que repetir tuplas en una tabla para variar unos pocos datos. O que eliminar un elemento
suponga eliminar varias tuplas.

FORMAS NORMALES
La forma normal se corresponde a una teoría de normalización iniciada por el propio Codd y continuada
por otros autores (entre los que destacan Boyce y Fagin). Codd definió en 1970 la primera forma normal,
desde ese momento aparecieron la segunda, tercera, la Boyce-Codd, la cuarta y la quinta forma normal.

Una tabla puede encontrarse en primera forma normal y no en segunda forma normal, pero no al contrario.
Es decir, los números altos de formas normales son más restrictivos (la quinta forma normal cumple
todas las anteriores).

La teoría de formas normales es una teoría absolutamente matemática, pero en el presente manual se
describen de forma intuitiva.

Primera forma normal (1FN)

Una tabla está en Primera Forma Normal si:

▪ Todos los atributos son “atómicos”. Por ejemplo, en el campo teléfono no tenemos varios
teléfonos.
▪ La tabla contiene una clave primaria única. Por ejemplo, la CURP para personas, la matrícula
para vehículos. Si no tiene clave, no es 1FN.
▪ La clave primaria no contiene atributos nulos. No podemos tener filas para las que no haya
clave (por ejemplo, personas sin CURP o vehículos sin matrícula).
▪ No debe existir variación en el número de columnas. Si algunas filas tienen 8 columnas y
otras 3, pues no estamos en 1FN.
▪ Los campos no clave deben identificarse por la clave. Es decir, que los campos no clave
dependen funcionalmente de la clave. Esto es prácticamente lo mismo que decir que existe
clave primaria.
▪ Debe existir una independencia del orden tanto de las filas como de las columnas, es decir,
si los datos cambian de orden no deben cambiar sus significados.

Segunda forma normal (2FN)

Ocurre si una tabla está en primera forma normal y además cada atributo que no sea clave,
depende de forma funcional completa respecto de cualquiera de las claves. Toda la clave principal
debe hacer dependientes al resto de atributos, si hay atributos que depende sólo de parte de la
clave, entonces esa parte de la clave y esos atributos formarán otra tabla.

Página No. X
Tercera forma normal (3FN)

Ocurre cuando una tabla está en 2FN y además ningún atributo que no sea clave depende
transitivamente de las claves de la tabla. Es decir, no ocurre cuando algún atributo depende
funcionalmente de atributos que no son clave.

Supongamos que tenemos una tabla de ganadores de torneos de tenis. En ella figura el nombre
del torneo, el año, el nombre del ganador y su nacionalidad. La clave sería Torneo-Año. Pues esta
tabla no está en 3FN porque el atributo nacionalidad, que no es de la clave, depende del nombre
del ganador (también depende de la clave). Digamos que nacionalidad aporta información sobre
el ganador, pero no sobre la clave. Es una dependencia transitiva porque nacionalidad depende de
ganador que a su vez depende de Torneo-Año.

Para nuestro ejemplo, las tablas quedaron normalizadas, hasta la tercera forma normal.

EJERCICIO DE PRÁCTICA 1:
Convertir el siguiente diagrama ER al esquema relacional, y posteriormente, mostrar la reducción a tablas.

Agregar, al menos, 5 tuplas a las tablas PACIENTE y MÉDICO.

Agregar, al menos, 5 registros a la relación.

Página No. XI