Modelo Relacional

E. F. Codd - modelo relacional en1970.

Antes: punteros físicos (direcciones de disco) relacionaban

registros de distintos archivos.
Relacionar registro A con registro B -> añadir a registro A un
campo conteniendo la dirección en disco de registro B.
Este campo siempre señalaría desde el registro A al registro B.

Vulnerabilidad: añadir un nuevo disco y mover los datos de

una localización física a otra ->conversión de los archivos de
datos.

Sistemas basados en modelo de red y modelo jerárquico,

primera generación de los SGBD.
Modelo relacional: segunda generación de los SGBD.

Datos estructurados a nivel lógico como tablas formadas por

filas y columnas.

A nivel físico pueden tener una estructura completamente

distinta.

Tablas pueden ser construidas:

•Crear conjunto de tablas iniciales y aplicar ciertas operaciones

hasta conseguir el esquema más óptimo.
•Convertir diagrama MER a tablas y posteriormente aplicar
también estas operaciones hasta conseguir el esquema óptimo.
Primera técnica: de las primeras en existir.
Segunda, más reciente, mucho más conveniente:

• Partir de un diagrama visual es muy útil para apreciar los detalles (modelo
conceptual).
• Crear tablas es mucho más simple a través de las reglas de conversión
(MER-Relacional).
• En ambos casos hay que aplicar operaciones a las tablas; al partir del MER
éstas son mínimas.
• Aún con normalizacion deficiente, se garantiza un esquema aceptable, no así
en la primera técnica.

Modelo relacional ve tres aspectos de los datos:

• Estructura de datos. (Aquí estamos)
• Integridad de datos.
• Manejo de datos.
 id_cliente número_cuenta
nombre_cliente (1,n) (1,n) saldo
calle_cliente Cliente tiene Cuenta
ciudad_cliente
Estructura

La relación es el elemento básico del modelo relacional y se

representa por una tabla.

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 (atributo): nombre, carnet, apellidos,
edad,....
Cada fila posee una ocurrencia o ejemplar de la instancia
representada por la tabla (tuplas).
Relación Tabla
Tupla Fila
Atributo Columna
Numero de Cardinalidad
tuplas
Numero de Grado
atributos
Dominio Colección de valores, de los cuales uno o más
atributos obtienen sus valores reales.
Clave primaria Identificador único para la tabla: una columna o
combinación de columnas con la propiedad de que
nunca existen 2 filas de la tabla con el mismo valor
en esa columna o combinación de columnas.
Pelicula
título año duración Tipo

Star Wars 1977 124 color

Mighty Ducks 1991 104 color

Wayne's World 1992 95 color

 Oficina
Onum Calle Area Población Teléfono Fax

O5 Enmedio, 8 Centro Castellón 964 201 240 964 201 340

O7 Moyano, s/n Centro Castellón 964 215 760 964 215 670

O3 San Miguel, 1 Villarreal 964 520 250 964 520 255

O4 Trafalgar, 23 Grao Castellón 964 284 440 964 284 420

O2 Cedre, 26 Villarreal 964 525 810 964 252 811

Plantilla
Fecha_na
Enum Nombre Apellido Dirección Teléfono Puesto Salario DNI Onum
c

Magallanes, 15 964 284

EL21 Amelia Pastor Director 12/10/62 30000 39432212 O5
Castellón 560

Bayarri, 11 964 535 Superviso

EG37 Pedro Cubedo 24/3/57 18000 38766623 O3
Villarreal 690 r
Borriol, 35 964 522
EG14 Luis Collado Administ. 9/5/70 12000 24391223 O3
Villarreal 230

Casalduch, 32 964 257 Superviso

EA9 Rita Renal 19/5/60 18000 39233190 O7
Castellón 550 r

Melilla, 23 964 524

EG5 Julio Prats Director 19/12/50 24000 25644309 O3
Villarreal 590
Herrero, 51 964 247 Superviso
EL41 Carlos Baeza 29/2/67 18000 39552133 O5
Castellón 250 r
Dominio

Cada atributo de una base de datos relacional se define sobre un dominio.

Varios atributos pueden estar definidos sobre el mismo dominio.
Permiten especificar los posibles valores válidos para uno o varios
atributos.

Un dominio D es un conjunto finito de valores homogéneos y atómicos

caracterizados por un nombre.
Homogéneo significa que los valores son todos del mismo tipo y atómicos
significa que son indivisibles.

El dominio "Nacionalidades" tiene valores: España, Francia, Chile,

Argentina...
Si descompusiéramos España en E,s,p,... perdería la semántica. (indivisible)
Ejemplos:

•Colores: Es el conjunto de los colores D={rojo, verde, azul}

•Números de DNI: Es conjunto de números del DNI válidos (0-9),
formados por ocho dígitos.
•Edad: Edades posibles de los empleados entre 18 y 80 años.

Cada domino debe tener un tipo de datos.

El tipo de datos del dominio "nacionalidades" es un conjunto de
caracteres de longitud 10.

Se considera que los dominios no incluyen nulos, ya que nulo

(NULL) no es un valor.
 Nombre del
Atributo Descripción Definición
Dominio

Posibles valores de 3 digitos; rango O1-

Onum NUM_OFICINA
número de oficina O99
Nombres de calles de
Calle NOM_CALLE 25 caracteres
España
Nombres de áreas de
Area NOM_AREA las poblaciones de 20 caracteres
España
Nombres de las
NOM_POBLACIO
Población poblaciones de 15 caracteres
N
España
Números de teléfono
Teléfono NUM_TEL_FAX 9 digitos
de España
Números de teléfono
Fax NUM_TEL_FAX 9 dígitos
de España
Tipos de Datos

Cada dominio debe definirse sobre algún tipo de dato:

Entero (Integer) Números enteros sin parte decimal.

Carácter (Char) Caracteres del código ASCII, de 0-255
Boleano (Boolean) Pueden contener los valores de falso o verdadero
Real Números que pueden incluir una parte decimal
En una secuencia de caracteres que se trata como
Cadena (String)
un solo dato.
Enteros Reales
Rango de valores Rango de valores que
Tipo  Tipo 
que acepta  acepta 
Integer  (Entero) -32,768 a 32,767  Real 2.9E-39 a 1.7E38
Word     (Palabra) 0 a 65535  Single  1.5E-45 a 3.4E38
ShortInt  (Entero
-128 a 127  Double  5.0E-324 a 1.7E308
corto)
Byte  0 a 255  Extended  1.9E-4851 a 1.1E4932
LongInt  (Entero -2,147,483,648 a
largo) 2,147,483,648  Comp  -9.2E18 a 9.2E18

Cuál utilizar dependerá del problema: qué valores se desea

almacenar.
Los tipos de datos a utilizar dependerán del SGBD.

Otros:
Fecha/Hora: para introducir datos en formato fecha u hora
Moneda: introducir datos en formato número y con el signo monetario
Autonumérico: se numera automáticamente el contenido
Nulos (NULL)

Un nulo no representa el valor cero ni la cadena vacía.

El nulo implica ausencia de información.

Necesidad de valores nulos cuando:

•Tuplas con atributos desconocidos en ese momento.
•Añadir un nuevo atributo a una tabla ya existente; atributo que en el
momento de introducirse no tendrá ningún valor para las tuplas de la
relación.
•Posibilidad de atributos inaplicables a ciertas tuplas, como la
editorial para un artículo.

En claves foráneas indican que el registro actual no está

relacionado con ninguna tabla.
Atributo

Un atributo A es el papel que tiene un determinado dominio en una

relación.
D es el dominio de A y se denota dom(A).

Es muy usual dar mismo nombre al atributo y al dominio.

Si varios atributos de una misma tabla están definidos sobre el
mismo dominio, hay que darles nombres distintos:
una tabla no puede tener dos atributos con el mismo nombre.

Atributos edad_física y edad_mental pueden estar definidos sobre

el mismo dominio edad; atributos precio_compra y precio_venta
pueden estar definidos sobre el mismo dominio precio, enteros de
longitud 5 mayores que 0.
Relación

Una relación se compone de una cabecera y un cuerpo.

Cabecera: formada por un conjunto de atributos, cada uno corresponde a un
único dominio.
No hay dos atributos que se llamen igual.

Cuerpo: formado por un conjunto de tuplas que varía en el tiempo; conjunto de

pares atributo:valor.
Cantidad de atributos: grado
Cantidad de tuplas: cardinalidad.

•Cabecera de relación OFICINA:

•{ (Onum:NUM_OFICINA), (Calle:NOM_CALLE), (Area:NOM_AREA), (Población:NOM_POBLACION),
(Teléfono:NUM_TEL_FAX), Fax:NUM_TEL_FAX)}.
•Una tupla:
•{ (Onum:O5), (Calle:Enmedio,8), (Area:Centro), (Población:Castellón), (Teléfono:964 201 240), (Fax:964
201 340)}.
Claves

•Clave candidata: conjunto no vacío de atributos que identifican

univoca y mínimamente a una tupla. Toda relación siempre tendrá
una.
•Clave primaria: clave candidata escogida para identificar a las
tuplas de una relación.
•Clave alternativa: claves candidatas no elegidas como primarias.
•Clave ajena o foránea de una relación R2: conjunto no vacío de
atributos cuyos valores han de coincidir con los valores de la clave
primaria de otra relación R1. Clave foránea y clave primaria han
de estar definidas sobre los mismos dominios.

Ningún componente de la clave primaria puede en algún momento

no tener valor (aceptar nulos).
Transformación MER-Relacional

Se transformará el esquema conceptual (MER) a un

esquema relacional.
Este esquema sigue siendo independiente de SGBD.

El paso del esquema MER al relacional se basa en los

siguientes principios:
 1. Todo tipo de entidad se convierte en relación.

Cada entidad del MER da lugar a una nueva relación.

•Identificador principal: atributo(s) que forman la clave primaria
de la nueva relación. Se subrayan.
Cada atributo de una entidad se transforma en un atributo de esta
relación. Tomar en cuenta:
•Atributos obligatorios: atributos que deben contar con un valor
en la tabla, no debe aceptar valores nulos. (restricción NOT NULL.)
•Atributos opcionales: atributos que pueden tomar valores nulos
(no se conoce el valor, etc, NULL)
•Identificador alternativo: atributo alternativo en la entidad que
debe ser único en la relación (restricción UNIQUE).
•Atributos monovaluados: dan lugar a un atributo de la relación.
 id _ clie n te
n o m b re _ clie n te
ca lle _ clie n te C liente
ciu d a d _ clie n te

Cliente (id_cliente, nombre_cliente, calle_cliente,

ciudad_cliente) PK: id_cliente

(PK: primary key->clave primaria)

•Atributos multivaluados: dan lugar a una nueva relación
cuya clave primaria es la concatenación de la clave primaria de
la entidad en la que está el atributo multivaluado mas el nombre
del atributo multivaluado.

id_c liente
nombre_c liente
direc c ion_c liente C liente
telefono_c liente

Cliente (id_cliente, nombre_cliente, direccion_cliente) PK:

id_cliente
Teléfonos_cliente (id_cliente, telefono_cliente) PK: id_cliente,
telefono_cliente; FK: id_cliente referencia a Cliente.

FK: foreign key->clave foranea)

•Atributos compuestos: se pueden transformar según las
siguientes alternativas:
•Eliminar el atributo compuesto considerando todos sus
componentes como atributos individuales.

c alle id_c liente

nombre_c liente
numero direc c ion_c liente C liente
telefono_c liente
c iudad

Cliente (id_cliente, nombre_cliente, calle, numero, ciudad,

telefono_cliente) PK: id_cliente

•Eliminar los componentes individuales y considerar el atributo

compuesto entero como un sólo atributo.
Cliente (id_cliente, nombre_cliente, direccion_cliente,
telefono_cliente) PK: id_cliente
Atributos derivados: atributos que se obtienen como
resultado de un calculo sobre otros atributos.
No existe para los atributos derivados una representación
directa y concreta en el modelo relacional y sus SGBD.
En este caso, los atributos se tratan de la forma usual.

Se calcula el valor del atributo derivado cada vez que se

inserten o borren las ocurrencias de los atributos que
intervienen en el cálculo de este.
Para esto se implementan los procedimientos del caso y se
añaden las restricciones correspondientes.
Atributos de Interrelaciones

Si la interrelación se transforma en una relación, todos sus

atributos pasan a ser columnas de la relación.

En caso de que la relación se transforme mediante

propagación de clave, sus atributos migran junto con la
clave a la relación que corresponda
Dependencia por identidad.

Una interrelación 1:N de dependencia en identificación da lugar a una

propagación de clave desde la entidad fuerte a la entidad débil. La
entidad débil requiere de la clave de la entidad fuerte para su
identificación. La clave queda formada por la concatenación de la
clave foránea y la clave de la entidad débil.

Có d igo
No mb re ( 1,1 ) (1 , N) Núm er o
I
Nr_ h oja s L ib ro
Libro (codigo, nombre, nr_hojas, editorial)
ti ene E jeje mp
PK: codigo la r
E st ado
m pla
E dito ria l P osició n
Ejemplar (codigo, numero, estado, posición) PK: codigo, numero FK:
codigo referencia a Libro.
2.Todo tipo de interrelación N:M se transforma
en relación.

Las interrelaciones N:M dan lugar a una nueva relación

cuya clave serán las claves primarias de las entidades que
enlaza la interrelación.

Los atributos que forman la clave primaria de esta nueva

relación son claves foráneas respecto a las tablas en
donde son claves primarias.
 id_ clie nte nú mero_cu enta
nombre_clie nte (1,n) (1,n) saldo
calle _clie nte Cliente tiene Cuenta
ciudad_clie nte

Cliente (id_cliente, nombre_cliente, calle_cliente,

ciudad_cliente) PK: id_cliente
Cuenta (numero_cuenta, saldo) PK: numero_cuenta
Tiene (id_cliente, numero_cuenta) PK. Id_cliente,
numero_cuenta FK: id_cliente referencia a Cliente,
numero_cuenta referencia a Cuenta.
 privilegio
id_cliente n úme ro_cuenta
nombre _cliente (1,n) (1,n) saldo
calle_cliente Cliente tiene Cuenta
ciuda d_cliente

Cliente (id_cliente, nombre_cliente, calle_cliente,

ciudad_cliente) PK: id_cliente
Cuenta (numero_cuenta, saldo) PK: numero_cuenta
Tiene (id_cliente, numero_cuenta, privilegio) PK. Id_cliente,
numero_cuenta FK: id_cliente referencia a Cliente,
numero_cuenta referencia a Cuenta.
 3. Todo tipo de interrelación 1:N se traduce en el
fenómeno de propagación de la clave.

Se propaga la clave primaria de la entidad que se encuentra en el

lado 1 a la entidad que se encuentra en el lado N.

numero_region
nombre_ciudad (1,n) (1,1) nombre_region
habitantes_ciudad Ciudad esta Region habitantes_region

Region (numero_region, nombre_region, habitantes_region) PK:

numero_region
Ciudad (nombre_ciudad, habitantes_ciudad, numero_region) PK:
nombre_ciudad, FK: numero_region referencia a Region.
 fec ha
có d ig o
cód ig o (1 ,1) (1,n ) no mb re
no mb re Proveedor s uminis tra Produc to pre cio _ u n itario
d ireccio n

Proveedor (codigo, nombre, direccion) PK: codigo

Vendedor (codigo, nombre, precio_unitario, codigo_prov,
fecha) PK: codigo, FK: codigo_prov referencia a Proveedor

Un aspecto importante en estas interrelaciones tiene que

ver con las cardinalidades mínimas.
Si la cardinalidad mínima de la entidad que se propaga es
1, significa que no pueden admitirse valores nulos en la
clave foránea (clave propagada).
En cambio, si es 0, si se admiten valores nulos.
 •Si en la parte de cardinalidad minima hay una participación parcial:

tasa_descuento
nombre_vend edor
numero_pedido (1,n) (0,1) fono
fecha Pedido s uminis tra Vendedor

Vendedor (nombre_vendedor, fono_vendedor) PK:

nombre_vendedor
Pedido (numero_pedido, fecha, tasa_descuento,
nombre_vendedor) PK: numero_pedido, FK: nombre_vendedor
referencia a Vendedor

En este caso puede ocurrir que tasa_descuento y

nombre_vendedor tomen valores nulos.
 •Si el número relativo de esos pedidos es grande, y no se puede
admitir valores nulos, una mejor alternativa:

tasa_desc uento
n o mb re _ ve n d e d o r
n u me ro _ p e d id o (1 ,n ) (0 ,1 ) fono
fe ch a Pedido s uminis tra Vendedor

Se crea una nueva relación para la interrelación cuyo tratamiento seria

igual que el de las interrelaciones N:M con la salvedad de que la clave
primaria de la nueva relación constara de la clave primaria de la
entidad que se encuentra en el lado N de la interrelación.
Vendedor (nombre_vendedor, fono_vendedor) PK: nombre_vendedor
Pedido (numero_pedido, fecha) PK: numero_pedido
Pedido_Ventas (numero_pedido, nombre_vendedor, tasa_descuento)
PK: numero_pedido, FK: numero_pedido referencia a Pedido,
nombre_vendedor referencia a Vendedor
•Si en la parte de cardinalidad maxima hay una participación parcial se
necesitan tres tablas:

CI_persona
patente_auto (0,n) (1,1) nombre_persona
marca_auto Auto es_prop Persona direccion_persona

Auto (patente_auto, marca_auto) PK: patente_auto

Persona (CI_persona, nombre_persona, direccion_persona) PK CI_persona
Auto_persona (CI_persona, patente_auto) PK: patente_auto, CI_persona,
FK: patente_auto referencia a Auto, CI_persona referencia a Persona

Se podría propagar también la clave de la entidad que tiene la cardinalidad

minima a la que tiene máximo N:
Auto (patente_auto, marca_auto, CI_persona) PK: patente_auto, FK
CI_persona referencia a Persona
Persona (CI_persona, nombre_persona, direccion_persona) PK CI_persona
 •Interrelaciones 1:1
•Si la relación es del tipo 1:1 y es obligatorio (total), cada entidad
se transforma en una tabla con clave principal el identificador de
la entidad correspondiente y cada tabla tendrá como clave ajena
el identificador de la otra tabla con la cual está relacionada.

CI_director
codigo_empresa (1,1) (1,1) nombre
direccion_empresa Empresa tiene Director

Empresa (codigo_empresa, direccion_empresa, CI_director) PK

codigo_empresa, FK CI_director referencia a Director
Director (CI_director, nombre, codigo_empresa) PK CI_director,
FK codigo_empresa referencia a Empresa
 •Una de las entidades tiene cardinalidad (0,1) y la otra (1,1),
conviene propagar la clave de la entidad con cardinalidad
(1,1) a la tabla resultante de la entidad de cardinalidad (0,1).
Esta clave foránea no debe aceptar valores nulos.

codigo_depto
codigo_empleado (1,1) (0,1) nombre_depto
nombre _empleado responsabl
Empleado e
Depto

Empleado (codigo_empleado, nombre_empleado) PK:

codigo_empleado
Depto (codigo_depto, nombre_depto, codigo_empleado) PK:
codigo_depto, FK: codigo_empleado referencia a Empleado.
•Si las entidades que se asocian tienen ambas cardinalidades
(0,1) se generan tres tablas, una para cada entidad y otra para la
relación que deberá contener como atributos las claves primarias
de las entidades que participan en la relación.
Se evitan los valores nulos que aparecerian en caso de propagar
una de las claves primarias.

fecha
codigo_animal
CI_persona (0,1) (0,1) no mbre _a nima l
n ombre_persona
Persona
Persona (codigo_persona, nombre_persona)
po see
PK: Animal
codigo_persona
Animal (codigo_animal, nombre_animal) PK: codigo_animal
Persona_Animal (codigo_persona, codigo_animal, fecha) PK:
codigo_persona, codigo_animal FK: codigo_persona referencia a
Persona, codigo_animal referencia a Animal.
•Relaciones reflexivas
Para transformarlas se debe suponer que se trata de una relación
binaria con la particularidad que las dos entidades son iguales y
aplicar las reglas vistas.

a p a d rin a
(1 ,n )
C I_ p e rso n a
n o m b re _ p e rso n a Persona
(1 ,1 )
Persona (CI_persona, nombre_persona, CI_o_persona) PK:
CI_persona FK: CI_o_persona referencia a Persona

La clave foránea no puede aceptar nulos (todas las personas tienen

un padrino).
Todas las personas de la base son padrinos de al menos una persona.
• El siguiente caso es igual que el anterior, con la
diferencia que la clave foránea si puede aceptar nulos
(una persona puede o no tener padrino).

a p a d rin a
(1 ,n )
C I_ p e rso n a
n o mb re _ p e rso n a P ersona
(0 ,1 )
• Los mismos esquemas se darán para los siguientes
casos. Aquí la diferencia es que una persona de la base
puede no aparecer como padrino de alguien (0,n). (No
todas las personas de la base son padrinos)

a p a d rin a
(0 ,n )
C I_ p e rso n a
n o m b re _ p e rso n a Persona
(1 ,1 )
• En el siguiente caso una persona de la base puede no
aparecer como padrino y una persona puede no tener
padrino, por lo que debe aceptar valor nulo en la clave
foránea.

a p a d rin a
(0 ,n )
C I_ p e rso n a
n o m b re _ p e rso n a P ersona
(0 ,1 )
•Casos N:M

Se tendria una tabla por entidad persona, y una tabla

representando la relación “apadrina”:
Persona (CI_persona, nombre_persona) PK: CI_persona
Apadrina (CI_persona, CI_o_persona) PK: CI_persona,
CI_o_persona FK: CI:persona, CI_o_persona referencia a
Persona
Generalizaciones
Las generalizaciones no son objetos que puedan
representarse directamente en el modelo relacional.
Ante una entidad y sus subtipos caben varias soluciones
de transformación, con la consiguiente pérdida de
semántica dependiendo de la estrategia elegida, las cuales
son 3:
Integrar la jerarquía de generalización en una sola entidad
uniendo los atributos de las subentidades y añadiendo
estos atributos a los de la superentidad.
Se añade un atributo discriminativo para indicar el caso al
cual pertenece la entidad en consideración.
Es aplicable a todos los casos, con todas las coberturas.
El problema es tener que manejar en algunos casos
demasiados valores nulos.
Las operaciones que sólo actuaban sobre una subentidad
tendrán que buscar ahora los casos correspondientes
dentro del conjunto completo de casos.
 matric ula_estudiante
nombre_estudiante

c arrera titulo_tesis

Estudiante (matricula_estudiante, nombre_estudiante,

carrera, titulo_tesis, tipo) PK: matricula_estudiante
Eliminar la superentidad reteniendo las subentidades.
Aquí los atributos heredados deben propagarse entre las
subentidades.
No es práctica para generalizaciones superpuestas o
parciales; sólo lo es para jerarquías totales y exclusivas.
Si el número de atributos de la superentidad (comunes a
toda las subentidades) es excesivo, su duplicación en el
esquema de cada subentidad no se justifica.
 rut_empleado
nombre_empleado

espec ialidad nr_supervisados

Ingeniero (rut_empleado, nombre_empleado, especialidad) PK:

rut_empleado
Gerente (rut_empleado, nombre_empleado, nr_supervisados) PK:
rut_empleado
Retener todas las entidades y establecer explícitamente las
interrelaciones entre la superentidad y las subentidades.
Esta alternativa se puede considerar como la más general
de las tres, ya que siempre es posible.
Las desventajas de este enfoque son que el esquema
resultante es bastante complejo y hay una redundancia
inherente al representar cada eslabón ES-UN en la
jerarquía original a través de una relación explícita.
Las ventajas, por otra parte, son que modela todos los
casos, lo que la hace más flexible ante cambios de
requerimientos
Es conveniente si la mayoría de las operaciones son
estrictamente locales respecto a la superentidad o a una
de las subentidades.
 nr_proy ec to
nombre_proy ec to

nr_modulos c ontratista princ ipal

Proyecto (nr_proyecto, nombre_proyecto) PK: nr_proyecto

Desarrollo_Sw (nr_proyecto, nr_módulos) PK:
nr_proyecto FK: nr_proyecto referencia a Proyecto
Subcontrato (nr_proyecto, contratista_principal) PK:
nr_proyecto FK: nr_proyecto referencia a Proyecto