4 DISEÑO DE BASES DE DATOS

RELACIONALES

4.1. INTRODUCCIÓN ____________________________________________________ 2

4.2. PROBLEMAS EN EL DISEÑO DE BASES DE DATOS RELACIONALES _____ 2
4.3. FASES DEL DISEÑO DE BASES DE DATOS _____________________________ 3
4.3.1. Recolección y análisis de requerimientos: ____________________________________ 4
4.3.2. Diseño conceptual: _______________________________________________________ 4
4.3.3. Diseño lógico de la base de datos (transformación de modelo de datos): ___________ 4
4.3.4. Diseño físico de la base de datos: ____________________________________________ 4
4.4.CONCEPTOS DEL MODELO E-R _______________________________________ 5
4.4.1. Presentación e historia del modelo:__________________________________________ 5
4.4.2. Entidades y atributos: ____________________________________________________ 5
4.4.3. Tipos de entidades: _______________________________________________________ 5
4.4.4. Tipos de atributos: _______________________________________________________ 7
4.4.5. Vínculo o relación: _______________________________________________________ 8
4.5. MODELO E-R EXTENDIDO __________________________________________ 11
4.5.1. Superclase y subclases: ___________________________________________________ 11
4.5.2. Agregado: _____________________________________________________________ 15
4.6. REDUCCIÓN DE UN DIAGRAMA E-R A TABLAS _______________________ 16
4.7. APROXIMACIÓN POR DESCOMPOSICIÓN ____________________________ 26
4.7.1. Dependencias Funcionales ________________________________________________ 26
4.7.2. Claves de una relación ___________________________________________________ 28
4.8. PROCESO DE NORMALIZACIÓN DE UNA RELACIÓN __________________ 29
4.8.1. Primera forma normal (1FN): _____________________________________________ 30
4.8.2. Segunda forma normal (2FN): ____________________________________________ 31
4.8.3. Tercera forma normal (3FN): _____________________________________________ 32
4.8.4. Forma Normal de Boyce-Codd (FNBC): ____________________________________ 34

1
4.1. INTRODUCCIÓN
En general, el objetivo del diseño de una base de datos relacional es generar un
conjunto de esquemas de relaciones que permitan almacenar la información con un mínimo
de redundancia, pero que a la vez faciliten la recuperación de la información. Una de las
técnicas para lograrlo consiste en diseñar esquemas que tengan una forma normal
adecuada. Para determinar si un esquema de relaciones tiene una de las formas normales se
requiere mayor información sobre la empresa del "mundo real" que se intenta modelar con
la base de datos. La información adicional la proporciona una serie de limitantes que se
denominan dependencias de los datos.

4.2. PROBLEMAS EN EL DISEÑO DE BASES DE DATOS

RELACIONALES
Antes de hablar de formas normales y dependencias de datos es conveniente
considerar los defectos que pueden tener una base de datos mal diseñada.

Supongamos las siguientes relaciones:

PERSONA (DNI, NOMBRE, APELLIDOS)
COCHE (MATRICULA, MARCA. TIPO, POTENCIA, COLOR)
TENER (DNI, MATRICULA, FECHA, PRECIO)

Si en lugar de las anteriores relaciones que componen la BD, optásemos por una
única relación, formada por los atributos de las tres, ésta tendría los siguientes defectos:

- En primer lugar, algunos datos serán redundantes; en general en esta relación una persona
aparecerá tantas veces como coches posea.

- Esta redundancia conlleva unos riesgos de incoherencia durante las actualizaciones: por
ejemplo, si resulta que el nombre de López no es Pedro sino Juan, hay que tener cuidado y
actualizar todas las tuplas en las que aparece López.

- Es preciso admitir la presencia de valores nulos en una relación de este tipo para poder
mantener en la base, coches sin propietarios o personas que no tienen coches. Si muchos de
los atributos no se aplican a todas las tuplas de la relación, acabaremos con un gran número
de nulos en esas tuplas. Esto puede originar un considerable desperdicio de espacio de
almacenamiento Ej: Si sólo el 10% de los empleados tiene oficinas individuales, no se
justificará incluir un atributo NUM_OFIC en la relación EMPLEADO; más bien,
podríamos crear una relación OFICINAS_EMPL (DNIEMP, NUM_OFIC) contenga
exclusivamente tuplas para los empleados con oficinas individuales.

Por lo tanto además de hacerse más complicada la actualización (inserción,

eliminación y modificación), se desperdicia espacio. Uno de los objetivos en el diseño de
esquemas es minimizar el espacio de almacenamiento que ocupan las relaciones base
(archivos). La agrupación de atributos en esquemas de relación tiene un efecto significativo
sobre el espacio de almacenamiento, se requiere más.

2
4.3. FASES DEL DISEÑO DE BASES DE DATOS

Mundo real

RECOLECCIÓN
Y ANALISIS DE
REQUERIMIENTOS

Requerimientos de la base de datos

DISEÑO CONCEPTUAL

Esquema conceptual
(en un modelo de datos de alto nivel)
(por ejemplo: modelo E/R)

Independiente de S.G.B.D.

DISEÑO LÓGICO
(TRANSFORMACIÓN DEL MODELO DE DATOS)
Específico para cada S.G.B.D.
Esquema (conceptual) lógico
(en el modelo de datos de S.G.B.D.)

DISEÑO FÍSICO

Esquema interno
(para el mismo S.G.B.D.)

3
4.3.1. Recolección y análisis de requerimientos:

Los diseñadores entrevistan a los futuros usuarios de la base de datos para recoger y
documentar sus necesidades de información. En paralelo, conviene definir los
requerimientos funcionales que consisten en operaciones (transacciones) que se aplicarán a
la base de datos, e incluyen la obtención de datos y la actualización.

4.3.2. Diseño conceptual:

Una vez recogidos todos los requerimientos, el siguiente paso es crear un esquema
conceptual para la base de datos mediante un modelo de datos conceptual de alto nivel.

Nosotros utilizaremos para el diseño de esquemas conceptuales el modelo E-R

(entidad-relación), que describe los datos como entidades, vínculos (relaciones) y atributos.

4.3.3. Diseño lógico de la base de datos (transformación de modelo de

datos):

El siguiente paso en el proceso de diseño consiste en implementar de hecho la base

de datos con un S.G.B.D. comercial, transformando el modelo conceptual al modelo de
datos empleado por el S.G.B.D. (jerárquico, red o relacional).

El esquema relacional contiene una descripción detallada de los requerimientos de

información de los usuarios, y contiene descripciones de los tipos de datos, relaciones entre
ellos y restricciones.

En nuestro módulo haremos la implementación con un S.G.B.D. relacional, por ser

de los modelos más utilizados en la actualidad.

4.3.4. Diseño físico de la base de datos:

En este paso se especifican las estructuras de almacenamiento internas y la

organización de los archivos de la base de datos.

4
4.4. CONCEPTOS DEL MODELO E-R

4.4.1. Presentación e historia del modelo:

El modelo E-R (entidad/relación o entity/relationship) fue propuesto por Peter P.

Chen entre los años 1976-1977. Posteriormente otros muchos autores han investigado y
escrito sobre el modelo, proporcionando importantes aportaciones y mejoras como el
modelo Entidad/Relación Extendido (ERE), por lo que realmente no se puede considerar
que exista un único modelo E-R estándar aunque hay ideas comunes a todas las variantes.

El modelo E-R es un modelo claramente conceptual que describe los datos como
entidades, relaciones (vínculos) y atributos y permite representar el esquema conceptual de
una base de datos de forma gráfica mediante los diagramas E-R.

4.4.2. Entidades y atributos:

El objeto básico que se representa en el modelo E-R es la entidad que es "cualquier

objeto del mundo real con existencia propia, sobre el cual queremos tener información en
una base de datos”. Una entidad puede ser un objeto con existencia física (una cierta
persona, una casa, un empleado, un coche,..) o un objeto con existencia conceptual (una
empresa, un puesto de trabajo, un curso universitario,...).

De hecho, se suele llamar entidad a un conjunto de entidades. Éste representa la

totalidad de las entidades del mismo tipo que comparten las mismas propiedades o
atributos. En los diagramas E-R se representan mediante un rectángulo y dentro del mismo
se indica el nombre. Por ejemplo: CLIENTE, PROVEEDOR, ARTICULO, COCHE, etc.
Debemos elegir nombres que comuniquen, hasta donde sea posible, el significado de cada
entidad. Normalmente se utilizan nombres en singular y no en plural.

EMPLEADO

4.4.3. Tipos de entidades:

a) Fuertes (o regulares), que son aquellas que tienen existencia por si mismas (Por
ejemplo, EMPLEADO). Las entidades fuertes se representan como se ha dicho con un
rectángulo con trazo simple.

EMPLEADO DEPARTAMENTO

5
b) Débiles, cuya existencia depende de otro tipo de entidad (Por ejemplo, FAMILIAR
depende de EMPLEADO. La desaparición de un empleado de la base de datos hace que
desaparezcan también todos los familiares del mismo). Estos tipos de entidades se
representan normalmente con un rectángulo con líneas de doble trazo. Estas entidades
normalmente no tienen suficientes atributos para formar una clave primaria.

EMPLEADO FAMILIAR

Cada entidad tiene propiedades específicas, llamadas atributos, que la describen.

Por ejemplo, una entidad PROVEEDOR puede describirse por su C.I.F., su nombre, su
teléfono, etc. Los atributos se representan por elipses que están conectadas a su entidad o
relación mediante una línea recta.

CIF nombre tfno

PROVEEDOR

Al conjunto de valores que puede tomar un atributo se le llama dominio del

atributo.

Toda entidad debe tener al menos un atributo que permita diferenciar unas entidades
particulares de otras, es decir que no toman nunca el mismo valor para dos entidades
particulares diferentes. A estos atributos se les llaman claves. En el diagrama E-R los
atributos clave deben aparecer destacados; por ejemplo, subrayando su nombre (por
ejemplo, CIF de la entidad PROVEEDOR).

CIF nombre tfno

PROVEEDOR

6
4.4.4. Tipos de atributos:

a) Simples o compuestos: Los compuestos están formados por un conjunto de atributos,

mientras que los simples no se pueden dividir.
dia

fecha mes
año

b) Monovaluados o multivaluados: Los monovaluados sólo pueden tener un valor para una
entidad particular, mientras que los multivaluados o múltiples pueden tener más de un
valor. Los multivaluados se representan mediante una elipse con trazado doble. (Por
ejemplo el atributo color de la entidad COCHE es un atributo multivaluado, pues un coche
puede estar pintado de varios colores). Otra manera de señalar un atributo multivaluado es
mediante la indicación de cardinalidad “(1,n)” ó “(0,n)”, que viene a significar “un atributo,
varios valores”.

matric modelo color matric modelo color

(1,n)

COCHE COCHE

c) Almacenados o derivados: Los derivados son atributos cuyo valor para una entidad
particular puede obtenerse en función de los valores almacenados en otros atributos. Se
representan mediante una elipse con trazo discontinuo. (Por ejemplo el atributo edad de la
entidad PERSONA es un atributo derivado porque se puede obtener en función del valor
del atributo fecha_nacimiento).

DNI nombre fecha_nac edad

PERSONA

d) Opcionales: Son aquellos que pueden tener un valor nulo (NULL).

DNI nombre teléfono

(0,1)

PERSONA

En 1979, Tardieu, propone tres reglas generales que debe cumplir una entidad:
• Tiene que tener existencia propia.
• Cada ocurrencia de un tipo de entidad debe poder distinguirse de las demás.
• Todas las ocurrencias de un tipo de entidad deben tener los mismos tipos de
propiedades (atributos).

7
4.4.5. Vínculo o relación:

Se puede definir como una correspondencia, asociación o conexión entre dos o más
entidades. En los diagramas E-R se representa gráficamente como un rombo y sus nombres
son verbos. Por ejemplo: VENDE, PERTENECE, etc.

PROVEEDOR VENDE ARTÍCULO

Una relación puede tener atributos descriptivos. Por ejemplo, en la relación anterior,
podría tener como atributo descriptivo fecha_venta (la fecha en que se hace la venta).

fecha_venta

PROVEEDOR VENDE ARTÍCULO

Grado de una relación es el número de entidades que participan en la relación. Se

puede restringir el modelo E-R para incluir sólo conjuntos de relaciones binarias, es decir
de grado 2 (es aconsejable). Ejemplos sobre el grado:

 Relaciones Binarias. Son las relaciones típicas. Se trata de relaciones que asocian
dos entidades.

 Relaciones Ternarias. Relacionan tres entidades. A veces se pueden simplificar en

relaciones binarias, pero no siempre es posible.
8
  Relaciones n-arias. Relacionan n entidades.

 Relaciones dobles. Se llaman así a dos relaciones distintas que sirven para
relacionar a las mismas entidades. Son más difíciles de manejar ya que al manipular
las entidades hay que elegir muy bien la relación a utilizar para relacionar los datos.

 Relación reflexiva. Es una relación que sirve para relacionar ejemplares de la

misma entidad (personas con personas, piezas con piezas, etc.).

Correspondencia de cardinalidad, expresa el número máximo de entidades que

están relacionadas con una única entidad del otro conjunto de entidades que interviene en la
relación. Aunque normalmente nos interesa sólo la cardinalidad máxima, a veces es útil
especificar la cardinalidad mínima. Según su cardinalidad, podemos clasificar las relaciones
de los siguientes tipos:

TIPO RELACIÓN REPRESENTACIÓN

1:1 Una a una: La cardinalidad máxima en 1 1

ambas direcciones es 1.

1:N Una a muchas: La cardinalidad máxima en 1 N

una dirección es 1 y en la otra muchos.

M:N Muchas a muchas: La cardinalidad máxima M N

en ambas direcciones en muchos.

Cardinalidad y tipos de participación de las entidades en una relación:

 Opcional (parcial): No todas las ocurrencias de una entidad tienen que estar
relacionadas con alguna de la otra entidad. Se representa mediante una línea con trazo
sencillo. (Por ejemplo, no toda persona posee animales, y no todo animal es posesión de
alguna persona. En este caso ambas entidades participan parcialmente en la relación).

Una o ninguna persona - (1,0) 1:N (0,N) - Ninguno o varios animales

PERSONA POSEE ANIMAL

9
 Obligatoria (total): Cualquier ocurrencia de una entidad debe estar relacionada con al
menos alguna de la entidad con la que esta relacionada. Se dice también, que existe una
participación total de ese conjunto de entidades en el conjunto de relaciones, y se
representa mediante una línea con trazo doble. (Por ejemplo, todo proveedor tiene que
vender algún artículo para serlo, y todo artículo es vendido por algún proveedor. En este
caso ambas entidades participan de forma total en la relación).

Un solo proveedor - (1,1) 1:N (1,N) - Uno o varios artículos

PROVEEDOR VENDE ARTÍCULO

En este ejemplo de este tipo de participación, un artículo no puede carecer de proveedor.

Otro tipo de notación sería:

En el ejemplo, cada equipo cuenta con varios jugadores. Un jugador juega como mucho en
un equipo y podría no jugar en ninguno. Cada entrenador entrena a un equipo (podría no
entrenar a ninguno), el cual tiene un solo entrenador como mucho y como poco.

Aún habría más tipos de notaciones, pero nos quedamos con la primera que es muy
completa y extendida.

10
4.5. MODELO E-R EXTENDIDO
El modelo E-R extendido pretende aportar soluciones a requerimientos un tanto más
complejos no contemplados en el modelo E-R propuesto por Codd. Son las relaciones de
herencia IS_A (es un) y las entidades débiles. Así se incorporan al modelo E-R dos nuevos
elementos:

4.5.1. Superclase y subclases:

 Una superclase o superentidad es todo tipo entidad sobre el que se definen subclases.
Como se trata de entidades, se representa al igual que ellas con un rectángulo.

 Una subclase o subentidad es un subconjunto del tipo entidad que tiene sentido en el
minimundo ya que tiene atributos particulares. Como se trata de entidades, se representa
al igual que ellas con un rectángulo.

El tipo de relación entre una superclase y sus subclases, se dice que es un tipo ES_UN
(IS_A). Este tipo de relación se representa, a diferencia del resto de relaciones, con un
triángulo. El tipo ES_UN puede ser disjunto (disjunct) o puede ser solapado (overlap).
Cuando las entidades pertenecientes a las subclases se relacionan con la superclase
mediante un tipo disjunto, una entidad no puede estar en dos subclases distintas. Cuando se
trata de un tipo solapado, una entidad puede estar en dos o más subclases distintas. Cuando
el tipo ES_UN es disjunto se denota con una “d” dentro del triángulo, por el contrario si es
solapado se denota con una “o” dentro del triángulo.
SUPERCLASE
ESPECIALIZACIÓN

GENERALIZACIÓN
RELACIÓN (IS_A) ES_UN

SUBCLASES

El proceso para determinar la necesidad de usar estos elementos puede producirse en

dos sentidos:

 Especialización: es el proceso de definir un conjunto de subclases más específicas a

partir de un tipo entidad. Comparten clave con la superentidad y los atributos de la
superclase se heredan a las subclases.

 Generalización: es el proceso de unificar entidades o suprimir las diferencias entre

varios tipos de entidad, identificando sus cualidades comunes en una entidad general o
superentidad. Los atributos de las subentidades son totalmente heterogéneos, es decir,
diferentes.

11
 El uso de este elemento esta justificado (y recomendado) en dos casos:

 Cuando las subclases tienen atributos particulares que no tiene la superclase.

 Cuando existen tipos de relación en los que participan solo algunas subclases.

Ejemplos para especialización:

IS_A “Disjunto” o Exclusivo. La superclase es siempre (1,1) y las subclases (0,1):

A veces también se representa un arco bajo el triángulo de la jerarquía.
matric modelo

VEHÍCULO
(1,1)

d
CC
tipo
(0,1) (0,1) (0,1)

COCHE BUS MOTO CARRERA

plazas tipo

IS_A “Overlap” o Solapado. La superclase es siempre (1,1) y las subclases (0,1) ó (1,1):

Nombre Dirección

ID_Empleado Salario

EMPLEADO Puesto
(1,1)

N_proyectos Especialidad
(0,1) (0,1) (0,1)

ARQUITECTO ADMINISTRATIVO INGENIERO

comisiones nivel pulsaciones experiencia

En la especialización anterior (lo es porque la clave la tiene la superentidad) los arquitectos,

administrativos e ingenieros heredan los atributos de EMPLEADO; el resto son atributos
propios de cada subentidad (experiencia pertenece sólo a los ingenieros, en este ejemplo).

12
Ejemplo para generalización. Gestión de artículos en venta y de exposición:
ID_Articulo Precio

ARTÍCULOS EN VENTA
(0,1)

d
ID_Cuadro ID_Fac
Titulo
(0,1) (0,1) (0,1)
dimensiones
Autor
CUADROS ESCULTURAS FACSÍMILES

Titulo Autor ID_Esc tamaño páginas

Titulo

En la ilustración anterior, ARTÍCULOS EN VENTA es una generalización de los

CUADROS, ESCULTURAS y FACSÍMILES. Se utiliza una clave distinta para esta
entidad. Incluso en este caso podría haber cuadros, esculturas o facsímiles que no están
relacionados con los ARTÍCULOS EN VENTA (la cardinalidad de artículos es 0,1).

Obligatoriedad:
En las relaciones ES_UN (tanto exclusivas como solapadas) se puede indicar el hecho de
que cada ocurrencia de la superclase tiene que especializarse obligatoriamente en alguna de
las subclases. Este hecho se marca con un círculo sobre el triángulo de la relación o
jerarquía.

En las relaciones ES_UN se usa a menudo, por ejemplo:

EMPLEADO

(1,1)

(0,1) (0,1) (0,1)

ARQUITECTO ADMINISTRATIVO INGENIERO

En el ejemplo, el personal tiene que ser obligatoriamente un arquitecto, y/o un

administrativo y/o un ingeniero; al menos una de las tres cosas (es decir, no puede haber
personal que no sea ninguna de estas tres cosas).

13
Entidades débiles:

Ya se ha comentado antes que una entidad débil es aquella cuya existencia depende de otra.
Ahora vamos a clarificar más estas entidades. Efectivamente, ocurren cuando hay una
entidad más fuerte de la que dependen. En la forma clásica se representaría de esta forma:

En el diagrama la relación entre las tareas y los trabajos es 1 a n (cada trabajo se compone
de n tareas). Una tarea obligatoriamente está asignada a un trabajo, por lo que, no tiene
sentido hablar de tareas sin hablar del trabajo del que forma parte.

Hay incluso (aunque no siempre) una dependencia de identificación ya que las

tareas se identifican por un número de tarea y el número de trabajo al que se asignan.

Esto es un síntoma definitivo de que se trata de una entidad débil.

Todas las entidades débiles tienen este tipo de relación 1 a n con respecto a la entidad
fuerte de la que depende su existencia, por eso se representan de esta otra forma:

No hace falta dibujar el rombo de la relación ni la cardinalidad, se sobreentiende el tipo y

cardinalidad (1 a n) que posee.
En ocasiones el identificador de la entidad débil (Id_Tarea) es suficiente para
identificar los ejemplares de dicha entidad, entonces ese identificador quedaría como clave
principal, pero el identificador de la entidad fuerte (Id_Trabajo) seguiría figurando como
clave externa en la entidad débil.

14
4.5.2. Agregado:

Es un elemento que permite relacionar una relación con otra entidad. Hasta el
momento solo se podían relacionar entidades. Este nuevo elemento permite relacionar
relaciones con entidades, o relaciones entre si siempre que el caso lo requiera.

PERSONA participa PROYECTO

supervisa

ORGANISMO

15
4.6. REDUCCIÓN DE UN DIAGRAMA E-R A TABLAS
El modelo conceptual E-R visto muestra el esquema general de la BD a un nivel cercano al
diseñador, por lo que se le puede considerar el verdadero mapa de la BD. Por ello, puede
dar soporte a distintos modelos lógicos de SGBD (relacional, jerárquico, red, etc.). El
modelo relacional (incompatible con el jerárquico, red, etc.), implica convertir las entidades
y relaciones del modelo E-R en tablas (“relaciones”). Hay que insistir en la diferencia de la
palabra “relación” en ambos modelos. En el modelo relacional una “relación” es una tabla
mientras que en el E-R es la asociación que se produce entre dos entidades.

a) Para las ENTIDADES:

 Se genera una tabla con los atributos de una entidad. La clave primaria de la tabla
es la misma que la de la entidad del modelo E-R.

matric modelo precio matric modelo precio

COCHE

 En el caso de entidades débiles, se genera una tabla con los atributos de la entidad
débil, más la clave primaria de la entidad fuerte. La clave primaria de la tabla generada por
la entidad débil estará formada por los atributos clave de la entidad débil en el modelo E-R
más los atributos clave de la entidad fuerte en el modelo E-R. Ver: NN.mdb (relación 1:N).

n_emp nombre fecha_nac nombre_f relacion

(1,1) 1:N (0,N)

tiene
EMPLEADO FAMILIAR

EMPLEADO FAMILIAR
n_emp nombre fecha_nac n_emp relacion nombre_f
25 Arturo Fuentes 15/04/1973 25 Padre Juan Fuentes
26 Daniel Azcona 31/01/1972 25 Madre Marta Palacios
27 Maria Cordón 18/12/1973 26 Padre Julio Azcona
26 Madre Sara Ezquerro
Según este ejemplo, un familiar sólo puede 26 Primo Daniel Azcona
pertenecer a un único empleado (1,1). Según este ejemplo, un empleado puede
tener cero o varios (0,N) familiares (por
ejemplo, si han muerto todos, un empleado
no tendría familiares…)

En el caso en el que se deseara plantear la posibilidad de incluir hermanos en la

tabla EMPLEADOS sin tener que repetir datos de familiares para dichos hermanos
en la tabla FAMILIAR, habría que usar tres tablas. Ver: NN2.mdb (relación M:N).
En ese caso, la tabla FAMILIAR ya no se trataría de una entidad débil.
16
b) Para las RELACIONES:

 Si la relación es del tipo 1:1 y es obligatorio (total) el tipo de participación de

ambas entidades, solo es necesaria una tabla con los atributos de las entidades que
participan en la relación. Como clave primaria se puede tornar cualquiera de las
claves de las entidades.

CIF denominación domicilio DNI nombre

1:1
(1,1) (1,1)
EMPRESA DIRECTOR

CIF denominación domicilio DNI nombre

Pues toda empresa tiene única y exclusivamente un director y viceversa…

 Si la relación es del tipo 1:1 y el tipo de participación de una entidad es obligatoria

(total) y el de la otra es opcional (parcial), son necesarias dos tablas. Cada una
contendrá los atributos de las entidades que participan en la relación. En la tabla
correspondiente a la entidad con participación obligatoria se añade una columna que
contendrá la clave primaria de la otra entidad (clave ajena). En ese caso dicha
columna no deberá tener duplicados (sin duplicados), cosa que se puede especificar
en nuestra aplicación de base de datos. Ver: 01-(11)-11.mdb
nombre
n_dept nombre Dni edad
1:1
(0,1) (1,1)
<-es
DEPARTAMENTO jefe EMPLEADO

DEPARTAMENTO EMPLEADO
n_dept nombre DNIJefe Dni nombre edad
1 Gerencia 10.017.325 16.821.345 Alberto 45
7.654.321 Luis 36
10.017.325 Carmen 37

Un empleado es jefe de 1 o 0 deptos Un departamento tiene 1 solo jefe.

17
  Si la relación es del tipo 1:1 y el tipo de participación es opcional (parcial) para las
dos entidades, entonces es necesario generar 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. Ver: 01-(11)-01.mdb.

DNI nombre codigo nombre edad

1:1
(0,1) (0,1)
PERSONA posee ANIMAL

PERSONA POSEE ANIMAL

DNI nombre DNI Codigo Codigo nombre edad

 Cuando la relación es del tipo 1:N, y la entidad del lado N es de participación

obligatoria (total) se necesita una tabla para cada entidad. A la tabla que representa
la entidad N se le añade un atributo que contenga la clave primaria de la entidad con
la que se relaciona (clave ajena). Ver: 11-(1N)-1N.mdb

fecha nombre

n_dept nombre dni edad

1:N
(1,1) (1,N)
tiene
DEPARTAMENTO EMPLEADO

DEPARTAMENTO EMPLEADO
n_dept nombre dni nombre edad fecha n_dept

Un empleado sólo pertenece a 1 Un departamento puede tener 1 o N

departamento. empleados.

18
 Cuando la relación es del tipo 1:N, y la entidad del lado N es de participación
optativa (parcial) se necesitan dos tablas, exactamente igual que en el caso del punto
anterior. Ver: 11-(1N)-0N-2.mdb
lugar
DNI nombre edad nombre
Codigo lugar

1:N
(1,1) (0,N)
PERSONA dirige PROYECTO

PERSONA PROYECTO
DNI Nombre edad DNIdire Codigo nombre lugar

Pensar cómo sería una relación recursiva 1:N.

 Cuando la relación es del tipo 1:N, y la entidad del lado 1 es de participación

optativa (parcial) se necesitan tres tablas: una para representar cada entidad y una
para representar la relación. Ver: 01-(1N)-01N.mdb

DNI nombre edad lugar

Codigo

1:N
(0,1) colabora (0/1,N)
AYUDANTE PROYECTO

AYUDANTE COLABORA PROYECTO

DNI Nombre edad DNI Codigo Codigo Lugar

En este ejemplo, tenemos que un ayudante puede colaborar en 0 o varios

proyectos, pero en un proyecto sólo puede colaborar un solo ayudante.

19
 Si la relación es del tipo M:N, se generan tres tablas, una para cada entidad y otra
que contiene los atributos propios de la relación más la claves primarias de las
entidades que participan en la relación. Ver: NM.mdb.
nombre

codigo lugar DNI edad

M:N
M N
PROYECTO trabaja PERSONA

PROYECTO TRABAJA PERSONA

Codigo lugar Codigo DNI DNI Nombre edad

Pensar cómo sería una relación recursiva M:N.

 En caso de que la relación fuera n-aria y de cardinalidad máxima N (por ejemplo

una relación ternaria M:N:P), el procedimiento sería el mismo que en el caso
anterior: se generaría una tabla por cada entidad y otra para la relación conteniendo
los atributos propios de la relación más las claves primarias de cada entidad.

Horario
Tel
direccion
Cod_C descripcion
nombre
M:N:P
(1,N) (1,M)
PROFESOR IMPARTE CURSO
Cod_P

especialidad (1,P) Nivel Turno

ASIGNATURA

Cod_A nombre

PROFESOR CURSO
Cod_P nombre direccion especialidad Tel Cod_C Descripción Nivel Turno

IMPARTE ASIGNATURA
Cod_P Cod_C Cod_A Horario Cod_A nombre

20
Otra forma más adecuada de expresar las tablas o “relaciones” en el modelo relacional es:

Para las Tablas:

PROFESOR (Cod_P, direccion, nombre, Tel, especialidad)

ASIGNATURA (Cod_A, nombre)
CURSO (Cod_C, descripción, nivel, turno)

Para la relación:

IMPARTE (Cod_A,Cod_C,Cod_P, Horario)

Para hallar el grado de participación de una entidad en el ejemplo indicado, simplemente

hay que preguntarse cuántas ocurrencias de ésta se dan para una ocurrencia concreta de
cada una de las otras dos entidades respectivamente. Por ejemplo:

- PROFESOR: ¿Cuántos profesores imparten una ASIGNATURA concreta en un

CURSO concreto?: Como mínimo 1 y como máximo N. Grado de participación =
(1,N)
- ASIGNATURA: ¿Cuántas asignaturas pueden ser impartidas por un PROFESOR
concreto en un CURSO concreto?: Como mínimo 1 y como máximo N. Grado de
participación = (1,N)
- CURSO: ¿En cuántos cursos se puede impartir una ASIGNATURA concreta por un
PROFESOR concreto?: Como mínimo 1 y como máximo N. Grado de participación
= (1,N)

 En caso de que la relación fuera n-aria y una de las entidades participase con
cardinalidad máxima de 1 y el resto de N (por ejemplo una relación ternaria 1:M:N),
el procedimiento sería el similar al caso anterior con la salvedad de que la calve
primaria de la entidad con cardinalidad máxima de 1 entraría a formar parte de los
atributos de la relación como un simple atributo no clave.

Otro ejemplo:

Fecha_O
Fecha_alta
Cod_V Destino
Nombre
(0/1,1) (1.N)
OFERTA Transpoorte
EMPLEADO VIAJE
Cod_E 1:M:N
Salario Tel
(1,M)
CLIENTE Tel

Cod_Cl Nombre

21
 EMPLEADO VIAJE
Cod_E Nombre Salario Fecha_alta Tel Cod_V Destino Transporte

VENDE CLIENTE
Cod_V Cod_Cl Cod_E Fecha_O Cod_Cl Nombre Tel
1 5 77
2 9 77
1 6 88

En el ejemplo, mientras que un empleado puede ofertar varios viajes a varios clientes, cada
viaje concreto que es ofertado a un cliente, se hace a través de un único empleado.

Formalmente, para las Tablas:

EMPLEADO (Cod_E, Nombre, Salario, Fecha_alta, Tel)

VIAJE (Cod_V, Destino, Transporte)
CLIENTE (Cod_Cl, Nombre, Tel)

Para la relación:

OFERTA (Cod_Cl,Cod_V,Cod_E, Fecha_V)

Para hallar el grado de participación de una entidad en el ejemplo indicado, simplemente

hay que preguntarse cuántas ocurrencias de ésta se dan para una ocurrencia concreta de
cada una de las otras dos entidades respectivamente. Por ejemplo:

- EMPLEADO: ¿Cuántos empleados ofrecen un VIAJE concreto a un CLIENTE

concreto?: Como mínimo 1 y como máximo 1. Grado de participación = (1,1)
- VIAJE: ¿Cuántos viajes pueden ser ofrecidos a un CLIENTE concreto por un
EMPLEADO concreto?: Como mínimo 1 y como máximo N. Grado de
participación = (1,N)
- CLIENTE: ¿A cuántos clientes se les puede ofrecer un VIAJE concreto por un
EMPLEADO concreto?: Como mínimo 1 y como máximo N. Grado de
participación = (1,N)

Otro ejemplo:
Fecha_V
Fecha_alta
Matricula Kilómetros
Nombre
(0/1,1) (1.N)
VENDE Modelo
EMPLEADO COCHE
Cod_E 1:1:N
Salario Tel
(0/1,1)
CLIENTE Tel

Cod_Cl Nombre

22
 EMPLEADO COCHE
Cod_E Nombre Salario Fecha_alta Tel Matricula Kilómetros Modelo

VENDE CLIENTE
Matricula Cod_Cl Cod_E Fecha_V Cod_Cl Nombre Tel

En el ejemplo, mientras que un empleado puede vender varios coches a varios clientes
respectivos, un coche es vendido a un único cliente por un único empleado.

Formalmente, para las Tablas:

EMPLEADO (Cod_E, Nombre, Salario, Fecha_alta, Tel)

COCHE (Matrícula, Kilómetros, Modelo)
CLIENTE (Cod_Cl, Nombre, Tel)

Para la relación:

VENDE (Matricula,Cod_Cl,Cod_E, Fecha_V)

Observación: Si todos los grados de participación menores son (1,1), se puede omitir la
tabla o relación VENDE y simplemente añadir como claves foráneas de la tabla coche, los
campos de clave primaria de las otras dos tablas (EMPLEADO y CLIENTE). Pero si hay
algún grado de participación (0,1), entonces sería necesaria la tabla VENDE.

Para hallar el grado de participación de una entidad en el ejemplo indicado, simplemente

hay que preguntarse cuántas ocurrencias de ésta se dan para una ocurrencia concreta de
cada una de las otras dos entidades respectivamente. Por ejemplo:

- EMPLEADO: ¿Cuántos empleados venden un COCHE concreto a un CLIENTE

concreto?: Como mínimo 1 y como máximo 1. Grado de participación = (1,1)
- COCHE: ¿Cuántos coches pueden ser vendidos a un CLIENTE concreto por un
EMPLEADO concreto?: Como mínimo 1 y como máximo N. Grado de
participación = (1,N)
- CLIENTE: ¿A cuántos clientes les puede ser vendido un COCHE concreto por un
EMPLEADO concreto?: Como mínimo 1 y como máximo 1. Grado de participación
= (1,1)

23
Otros tipos de relaciones 1:M:N podrían ser:

- Varios empleados (1,N) pueden tener varios títulos universitarios (1,N),

cada uno expedido por una única universidad (1,1) por empleado y en una
fecha determinada.

- Varios pacientes (1,N) pueden recibir varias vacunas (1,N) cada una
aplicada por un único/a facultativo/a de salud (1,1) por paciente en una
fecha determinada.

Otros tipos de relaciones 1:1:N podrían ser:

- Un libro es escrito por un único autor (1,1) y es publicado a través de una

única editorial (1,1), pudiendo un autor escribir varios libros (1,N).

c) Para atributos multivaluados:

 Para estos atributos se generan tablas separadas, con la clave primaria del conjunto
de entidades o relaciones al que pertenecen.

matric modelo color COCHE COLOR-COCHE

matric modelo matric color

COCHE

d) Para la especialización y generalización:

 Se crea una tabla para la superentidad, superclase o conjunto de entidades del nivel
más alto.

 Para el conjunto de subentidades o entidades de nivel inferior, además de crear

tablas cuyos campos representen cada uno de los atributos respectivos de ese
conjunto de subentidades, se añade una columna adicional como clave externa que
importe la clave primaria de la superentidad. Como normalmente, en las
especializaciones, las entidades de nivel inferior no tienen claves primarias, esta
clave externa será también su clave primaria.

24
 matric modelo

VEHÍCULO
(1,1)

d CC
tipo tipo
(0,1) (0,1) (0,1)
COCHE AUTOBÚS MOTO

plazas

matric modelo

VEHÍCULO
(1,1) (1,1) (1,1)
Es_un Es_un Es_un
CC
tipo tipo
(0,1) (0,1) (0,1)
COCHE AUTOBÚS MOTO

plazas

VEHÍCULO COCHE AUTOBUS MOTO

matric modelo matric tipo matric plazas matric tipo CC
LO-123 gasolina LO-123 todo-terreno LO-234 40 LO-345 carretera 250
LO-234 diesel
LO-345 gasolina

25
4.7. APROXIMACIÓN POR DESCOMPOSICIÓN
La aproximación por descomposición para concebir esquemas relacionales parte de
una relación compuesta de todos los atributos obtenidos en la fase de recolección y análisis
de requerimientos llamada relación universal para descomponer después esta relación en un
conjunto de relaciones normalizadas. Es un proceso de depuración sucesiva que debe lograr
aislar unas entidades y asociaciones del mundo real, evitando que se produzca redundancia
de datos.

"La descomposición consiste, en la sustitución de la relación universal R

(A1,A2,...,An) por una serie de relaciones R1, R2, ..., Rn obtenidas mediante proyecciones
de R y tales que la relación resultante de las reuniones de R1,R2, ..., Rn tiene el mismo
esquema que R". La descomposición se debe hacer sin pérdidas, es decir, que la extensión
de las relaciones normalizadas nos permita obtener todos los valores de R.

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

- Redundancias: datos que se repiten contínua e inncecesariamente.

- Ambigüedades: datos que no clarifican suficientemente al registro al que

representan.

- Pérdida de restricciones de integridad: normalmente debido a dependencias

funcionales.

- Anomalías en operaciones de modificación de datos: El hecho de que al

actualizar un solo elemento haya que hacerlo en varias tuplas simultáneamente.

En cualquier caso la mayor parte de problemas se agravan si no se sigue un modelo

conceptual y se decide crear directamente el esquema relacional. En ese caso el diseño tiene
una garantía casi asegurada de funcionar mal.

Cuando aparecen algunos de los problemas citados entonces se les puede resolver usando
reglas de normalización. Estas reglas suelen forzar la división o descomposición sin
pérdidas de una tabla en dos o más tablas para arreglar ese problema.

4.7.1 Dependencias Funcionales

Codd introdujo el concepto de dependencia funcional para caracterizar aquellas

relaciones que pueden descomponerse sin pérdida de informaciones. Se puede definir la
dependencia funcional (D.F.) de la siguiente forma:

26
 "Dados dos atributos o dos conjuntos de atributos A y B de una relación R,
se dice que B es funcionalmente dependiente de A, si para cada valor de A
existe un valor de B, y sólo uno, asociado con él”.

En otros términos, se puede decir que si dos tuplas de una relación R tienen el
mismo valor en el atributo A deben tener el mismo valor en el atributo B. O dicho de otro
modo, si conocemos el valor de A podemos conocer el valor de B. Esto se representa como:

DF: A  B
La notación -> se lee "determina funcionalmente".

Por ejemplo, en una relación de CLIENTES (Número_cliente, Nombre, Apellidos,

Teléfono), existen las siguientes dependencias funcionales:

DF: Número_cliente → Nombre

DF: Número_cliente → Teléfono

Con este ejemplo se aprecia que el nombre de una persona depende funcionalmente del
DNI, ya que para un DNI concreto sólo hay un nombre posible. De la misma manera, para
un DNI concreto sólo hay un nº de teléfono concreto. En cambio para un mismo nombre,
pueden existir dos DNI’s diferentes, por lo que se considera que el DNI no depende
funcionalmente del nombre.

Dependencia funcional completa

Un conjunto de atributos (Y) tiene una dependencia funcional completa sobre otro conjunto
de atributos (X) si Y tiene dependencia funcional de X y además no se puede obtener de X
un conjunto de atributos más pequeño que consiga una dependencia funcional de Y (es
decir, no hay en X un determinante formado por atributos más pequeños).

Por ejemplo en una tabla de clientes, el conjunto de atributos formado por el Nombre y el
DNI producen una dependencia funcional sobre el atributo Apellidos. Pero no es plena ya
que el DNI sólo también produce una dependencia funcional sobre Apellidos. El DNI sí
produce una dependencia funcional completa sobre el campo Apellidos.

Una dependencia funcional completa se denota como X⇒Y

DNI Nombre Apellidos Teléfono

1234567G Alfredo González 941 11 11 11
1234568H Juan González 941 22 22 22
1234577I Juan Fernández 941 33 33 33
1234578J Alfonso Fernández 941 33 33 33

Como se puede apreciar en el ejemplo

DNI,Nombre→Apellidos, pero en realidad DNI⇒Apellidos

También podría decirse que DNI⇒ Nombre, Apellidos, Teléfono

27
Dependencia funcional elemental

Se produce cuando X e Y forman una dependencia funcional completa y además Y es un

único atributo.

Refiriéndonos al ejemplo anterior:

DNI⇒Nombre

Dependencia funcional transitiva

Se produce cuando tenemos tres conjuntos de atributos X, Y y Z. Y depende

funcionalmente de X (X→Y), Z depende funcionalmente de Y (Y→Z). Además X no
depende funcionalmente de Y (Y-/→X). Entonces ocurre que X produce una dependencia
funcional transitiva sobre Z. Esto se denota como:

(X ─→Z)

Por ejemplo:

Si X es el atributo Código de Clase de un instituto, e Y es el atributo Código Tutor.

Entonces X→Y (el tutor depende funcionalmente del código de clase).

Por otro lado, si Z representa el Código del departamento, entonces Y→Z (el código del
departamento depende funcionalmente del código tutor ya que cada tutor sólo puede estar
en un departamento).

Como ocurre que Y-/→X (el código de la clase no depende funcionalmente del código tutor,
un código tutor se puede corresponder con varios códigos de clase). Entonces X─→Z (el
código del departamento depende transitivamente del código de la clase).

Número de Clase─→ Código del departamento

Así pues para comenzar el proceso de normalización tenemos que estudiar las
propiedades de todos los atributos de la relación y analizar como están relacionados entre
sí, buscando las posibles dependencias funcionales que existan. Otro de los pasos previos al
proceso de normalización es decidir cuál es la clave primaria de la relación.

4.7.2. Claves de una relación

La clave de una relación es el conjunto mínimo de atributos que nos permite

diferenciar cada fila de una relación de todas las demás. Si la clave está formada por más de
un atributo se le llama clave compuesta.

En una relación puede que más de un conjunto de atributos puedan ser elegidos
como clave. A estos atributos se les llama claves candidatas y a la clave candidata elegida

28
como clave de la relación se le llama clave primaria y al resto de claves candidatas se les
llama claves secundarias o alternativas.

Una notación común que se usa para representar el esquema de una relación, como
la del ejemplo, es:

Cliente (numero_cliente, nombre, dirección, teléfono)

• Cliente es el nombre de la tabla.

• número_ cliente, nombre, dirección y teléfono son los atributos (columnas)
• número_cliente, es el nombre de la clave.

También se puede decir que un atributo o conjunto de atributos X es clave, si se cumple:

1. X → Al, A2, ..., An
2. No existe ningún atributo o conjunto de atributos Y, contenido en X, tal que
Y → Al, A2, ..., An

En otras palabras, una clave es un “conjunto mínimo de atributos que determina a

todos los demás”.

4.8. PROCESO DE NORMALIZACIÓN DE UNA RELACIÓN

En el proceso de normalización, según la propuesta original de Codd (1972), se
somete un esquema de relación a una serie de pruebas para "certificar” si pertenece o no a
una cierta forma normal. En un principio, Codd propuso tres formas normales, a las cuales
llamó primera, segunda y tercera formas normales (1FN, 2FN, 3FN). Posteriormente,
Boyce y Codd propusieron una definición más estricta de 3FN, a la que se conoce como
forma normal de Boyce-Codd (FNBC). Todas estas formas normales se basan en las
dependencias funcionales entre los atributos de una relación. Más adelante se propusieron
una cuarta forma normal (4FN) y una quinta (5FN), con fundamento en los conceptos de
dependencias multivaluadas y dependencias de reunión, respectivamente.

La normalización de los datos puede considerarse como un proceso durante el cual

los esquemas de relación que no cumplen las condiciones se descomponen repartiendo sus
atributos entre esquemas de relación más pequeños que cumplen las condiciones
establecidas. Un objetivo del proceso de normalización es garantizar que no ocurran
anomalías de actualización.

Las formas normales, consideradas aparte de otros factores, no garantizan un buen

diseño de BD. En general no basta con comprobar por separado que cada esquema de
relación de la BD esté en, digamos, FNBC o 3FN. Más bien, el proceso de normalización
por descomposición debe confirmar la existencia de propiedades adicionales que los
esquemas relacionales, en conjunto, deben poseer. Dos de estas propiedades son:

 La propiedad de reunión sin pérdida, que garantiza que no se presentará el problema de

las tuplas erróneas.

29
 La propiedad de conservación de las dependencias, que asegura que todas las
dependencias funcionales estén representadas en alguna de las relaciones individuales
resultantes.

La utilidad práctica de las formas normales queda en entredicho cuando las

restricciones en las que se basan son difíciles de entender o de detectar por parte de los
diseñadores de BD y usuarios que deben descubrir estas restricciones.

Otra de las consideraciones que hay que tener en cuenta es que 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 los

presentes apuntes se describen de forma más intuitiva.

Hay que tener en cuenta que muchos diseñadores opinan que basta con llegar a la
forma Boyce-Codd, ya que la cuarta, y sobre todo la quinta, forma normal es polémica. Hay
quien opina que hay bases de datos peores en quinta forma normal que en tercera. En
cualquier caso debería ser obligatorio para cualquier diseñador llegar hasta la forma normal
de Boyce-Codd.

Otro punto que merece la pena destacar es que los diseñadores de BD no tienen que
normalizar hasta la forma normal más alta posible. Las relaciones pueden dejarse en formas
normales inferiores por razones de rendimiento (Ej.: la relación EMP-DEPTO (NOMBRE,
NSS, FECHAN, DIRECCION, NUMEROD, NOMBRED, NSSJEFED) la dejaríamos así,
sin dividir, si por ejemplo una consulta importante obtiene información relativa -al
departamento de un empleado, junto con los atributos del empleado. Pero hay que tomar
nota de sus anomalías y entenderlas perfectamente de modo que, al actualizar la relación,
no se produzcan inconsistencias).

4.8.1. Primera forma normal (1FN):

“Una relación está en primera forma normal (1FN) si los valores para cada
atributo de la relación son atómicos”.

Esto quiere decir simplemente que cada atributo sólo puede pertenecer a un dominio
(es indivisible) y que tiene un valor único para cada fila.

La primera forma normal se definió para prohibir los atributos multivaluados, compuestos y
sus combinaciones. Así, se trata de una forma normal inherente al esquema relacional. Es
decir toda tabla realmente relacional la cumple, ya que no puede tener atributos
multivaluados.

Cuando una relación no está en primera forma normal, se divide en otras relaciones,
repartiendo sus atributos entre las resultantes. Normalmente la idea es eliminar el atributo

30
que viola la 1ª FN de la relación original y colocarlo en una relación aparte junto con la
clave primaria de la relación de partida. Ejemplo:

TRABAJADOR
DNI Nombre Departamento
12121212B Andrés Mantenimiento
12345345G Andrea Dirección
Gestión

TRABAJADOR es una tabla, pero no una tabla relacional (lo que en terminología de bases
de datos relacionales se llama relación). No cumple la primera forma normal.

- Una forma de conseguir que lo cumpla es modificar los valores de la tabla de la

siguiente manera:

TRABAJADOR
DNI Nombre Departamento
12121212B Andrés Mantenimiento
12345345G Andrea Dirección
12345345G Andrea Gestión

- Otra forma mejor de conseguir que cumpla la 1FN es desdoblar la tabla original en
dos tablas tal como se explicó para los atributos multivaluados:

TRABAJADOR
DNI Nombre
12121212B Andrés
12345345G Andrea

DEPARTAMENTO
DNI Departamento
12121212B Mantenimiento
12345345G Dirección
12345345G Gestión

4.8.2. Segunda forma normal (2FN):

“Una relación está en segunda forma normal si está en la 1ª FN y todos los

atributos no clave dependen de la clave completa y no sólo de una parte de
esta”.

Este paso sólo se aplica a relaciones que tienen claves compuestas, es decir, que
están formadas por más de un atributo. Si un esquema de relación no está en 2ªFN, se le
puede normalizar a varias relaciones en 2ªFN en las que los atributos que dependen de una
parte de la clave formarán una nueva relación que tendrá esa parte de la clave como clave
primaria. Cada atributo que no forma parte de la clave principal tiene que tener una
dependencia funcional completa de la clave principal.

31
Ejemplo:

DNI Cod_Asignatura Nombre Apellido1 Nota

12121219B 34 Pedro Valiente 9
12121219B 25 Pedro Valiente 8
3457775G 34 Ana Fernández 6
5674378J 25 Ana Crespo 7
5674378J 34 Ana Crespo 6

Suponiendo que el DNI y el código de curso formen una clave principal para esta tabla,
sólo la nota tiene dependencia funcional completa. El nombre y los apellidos dependen de
forma completa del DNI. Esto es:

DNI⇒Nombre,Apellido1

DNI,Cod_Asignatura⇒Nota

Por lo tanto, la tabla no está en 2FN. Para arreglarlo:

DNI Nombre Apellido1

12121219B Pedro Valiente
3457775G Ana Fernández
5674378J Sara Crespo

DNI Cod_Asignatura Nota

12121219B 34 9
12121219B 25 8
3457775G 34 6
5674378J 25 7
5674378J 34 6

Teorema de la 2FN:

Sea una relación(tabla) formada por los atributos A,B,C,D con clave primaria
compuesta por los atributos A y B. Si se cumple que (D depende funcionalmente de A):
A→D, entonces la relación se descompone en dos relaciones R1 y R2 con los atributos
respectivos: R1 (A,D) y R2 (A,B,C).

4.8.3. Tercera forma normal (3FN):

"Una relación está en tercera forma normal si todos los atributos de la

relación dependen funcionalmente sólo de la clave, y no de ningún otro
atributo".

Es decir, dicho de una manera muy general y sencilla, ocurre cuando ningún atributo
depende funcionalmente de atributos que no son clave, o lo que es lo mismo, cuando no
existen dependencias transitivas.

32
 Esto significa que en una relación en 3FN, para toda DF: X → Y, X es una clave.

Podemos observar que si una relación está en tercera forma normal, está también en
segunda forma normal, sin embargo lo inverso no siempre es cierto.

Ejemplo:

DNI Nombre Apellido1 Cod_Provincia Provincia

12121219B Salvador Velasco 34 Palencia
52121349B Pedro Valiente 34 Palencia
3457775G Ana Fernández 47 Valladolid
5674378J Sara Crespo 47 Valladolid
3456858S Marina Serrat 08 Barcelona

La Provincia depende funcionalmente del código de provincia, lo que hace que no esté en
3FN. Es decir, existe la dependencia transitiva DNI→Cod_Provincia→Provincia.

Por lo tanto el arreglo sería:

DNI Nombre Apellido1 Cod_Provincia

12121219B Salvador Velasco 34
52121349B Pedro Valiente 34
3457775G Ana Fernández 47
5674378J Sara Crespo 47
3456858S Marina Serrat 08

Cod_Provincia Provincia
34 Palencia
47 Valladolid
08 Barcelona

Teorema de la 3FN:

Sea una relación(tabla) formada por los atributos A,B,C con clave primaria formada por
el atributo A. Si se cumple que: B→C, entonces la relación puede descomponerse en dos
relaciones, R1 y R2, con los atributos respectivos:

- R1(A,B)

- R2(B,C)

Nota: Los conceptos del modelo ER (entidades, relaciones, atributos, claves y restricciones
estructurales) que hemos visto son suficientes para modelar algunas aplicaciones sencillas
de bases de datos, sin embargo para algunas aplicaciones es necesario utilizar conceptos
adicionales si lo que se quiere es un modelado más exacto.

33
4.8.4. Forma normal de Boyce-Codd (FNBC):

"Una relación está en forma normal de Boyce-Codd si está en 3FN y además

todo determinante de ésta es una clave candidata".

Es decir, todo determinante significa todo atributo o conjunto de atributos del cual/es
dependen otro/s.

Que un determinante sea una clave candidata implica que sus valores no se repiten (sin
duplicados) en ninguna otra tupla de la tabla.

Otra forma de entenderlo es decir que todo atributo no primario depende de la clave y
existe parte de la clave que depende de algún atributo no primario.

Ejemplo:
Supongamos una tabla o relación que identifique el Tutor o profesor de cada
asignatura en la que se han matriculado una serie de alumnos en una academia de estudios
de modo que cada Tutor o profesor sólo pueda serlo de una asignatura en concreto.

TUTOR_ALUMNO
DNI_alumno Asignatura Tutor
12121219B Lenguaje Eva
52121349B Matemáticas Andrés
3457775G Lenguaje Eva
5674378J Matemáticas Guillermo
5674378J Lenguaje Julia
3456858S Matemáticas Guillermo

Esa tabla está en tercera forma normal (no hay dependencias transitivas), pero no en forma
de Boyce - Codd, ya que:

(DNI_alumno, Asignatura) →Tutor

y
Tutor→Asignatura. (Aquí el determinante “Tutor” no es clave candidata ya que sus
valores se repiten)

En este caso la redundancia ocurre por mala selección de clave. La redundancia de la

asignatura es completamente evitable. La solución sería:

TUTORÍAS
DNI Tutor
12121219B Eva
52121349B Andrés
3457775G Eva
5674378J Guillermo
5674378J Julia
3456858S Guillermo

34
ASIGNATURAS_TUTOR
Tutor Asignatura
Eva Lenguaje
Andrés Matemáticas
Guillermo Matemáticas
Julia Lenguaje

Teorema de la FNBC:

Sea una relación(tabla) formada por los atributos A,B,C con clave primaria formada por
los atributos A, B de modo que: A,B→C. Si también se cumple que C→B, entonces la
relación puede descomponerse en dos relaciones, R1 y R2, con los atributos respectivos:

- R1(A,C)

- R2(C,B)

35