UNIDAD III.

EL MODELO DE DATOS RELACIONAL

Objetivo: Al finalizar la unidad, el estudiante estar en la capacidad de convertir el modelo
conceptual de la base de datos, representado en el diagrama E
E-R,
R, en el modelo lgicolgico
relacional y validar las relaciones obtenidas a travs del proceso de normalizacin.
3.1 Introduccin.
En este apartado se presenta el modelo relacional, que es el modelo lgico en el que se
basan la mayora de los SMBD comerciales, en uso hoy da. En la primera parte de esta
unidad, se describen los conceptos bsicos del modelo relacional: la estructura de datos
relacional y las reglas de integridad. Luego, se presenta la cconversin
onversin del modelo conceptual
de la base de datos (Diagrama Entidad
Entidad-Relacin) al modelo lgico-relaci
relacional. Por ltimo, se
presenta el proceso de n
normalizacin de las relaciones.
3.2 El Modelo Relacional.
En 1970, el modo en que se vean las bases de datos cambi por completo cuando E. F.
Codd introdujo el modelo relacional. En aquellos momentos, el enf
enfoque existente para la
estructura de las bases de datos utilizaba punteros fsicos (direcciones de disco) para
relacionar registros de distintos ficheros. Si, por ejemplo, se quera relacionar un registro
con un registro
, se deba aadir al registro
un
n campo conteniendo la direccin en disco
del registro
. Este campo aadido, un puntero fsico, siempre sealara desde el registro
al registro
. Codd demostr que estas bases de datos limitaban en gran medida los
tipos de operaciones que los usuarios podan realizar sobre los datos. Adems, estas bases
de datos eran muy vulnerables a cambios en el entorno fsico. Si se aadan los controladores
de un nuevo disco al sistema y los datos se movan de una localizacin fsica a otra, se
requera una conversin
in de los ficheros de datos. Estos sistemas se basaban en el modelo de
datos de red y el modelo jerrquico, los dos modelos lgicos que constituyeron la primera
generacin de los SMBD.
El modelo relacional representa la segunda generacin de los SMBD. En l, todos los
datos estn estructurados a nivel lgico como tablas formadas por filas y columnas, ver figura
3.1; aunque a nivel fsico puede tener una estructura completamente distinta. Un punto fuerte
del modelo relacional es la sencillez de su estructura
estructura lgica. Pero detrs de esa simple
estructura hay un fundamento terico importante del que carecen los SMBD de la primera
generacin, lo que constituye otro punto a su favor.

Las Filas son

los registros o
tuplas de la
relacin.

NumOficina

Poblacin

Telfono

Fax

O5

Enmedio, 8

Calle

Castelln

9640124

9642130

O7

Moreno, s/n

Castelln

9642576

9642567

O3

San Miguel, 1

Villarreal

9645225

9645025

O4

Bermdez, 23

Castelln

9642444

9642440

Las columnas
son los campos
o atributos de la
relacin.

Figura N 3.1 Relacin OFICINA de la base de datos Inmobiliaria, indicando sus partes.
Fuente: El autor, 2009.

El modelo relacional, como todo modelo de datos, tiene que ver con tres aspectos de los
datos:

 Estructura de datos.
Integridad de datos.
Manejo de datos.

3.3 Estructura de Datos.

3.3.1 Relaciones.
El modelo relacional se basa en el concepto matemtico de relacin, que grficamente se
representa mediante una tabla. Codd, que era un experto matemtico, utiliz una terminologa
perteneciente a las matemticas, en concreto el de la teora de conjuntos y de la lgica de
predicados.
Una relacin es una tabla con columnas y filas. Un SMBD slo necesita que el usuario
pueda percibir la base de datos como un conjunto de tablas. Esta percepcin slo se aplica a
la estructura lgica de la base de datos (nivel conceptual o lgico de la arquitectura de tres
niveles ANSI-SPARC). No se aplica a la estructura fsica de la base de datos, que se puede
implementar con distintas estructuras de almacenamiento.
Un atributo es el nombre de una columna de una relacin. En el modelo relacional, las
relaciones se utilizan para almacenar informacin sobre los objetos que se representan en la
base de datos. Una relacin se representa grficamente como una tabla bidimensional en la
que las filas corresponden a registros individuales y las columnas corresponden a los campos
o atributos de esos registros. Los atributos pueden aparecer en la relacin en cualquier orden.
La figura 3.1 muestra la relacin OFICINA que tiene cinco atributos.
Un dominio es el conjunto de valores legales de uno o varios atributos. Los dominios
constituyen una poderosa caracterstica del modelo relacional. Cada atributo de una base de
datos relacional se define sobre un dominio, pudiendo haber varios atributos definidos sobre el
mismo dominio. La tabla de la figura 3.2 muestra los dominios de los atributos de la relacin
OFICINA de la figura 3.1. Ntese que en esta relacin hay dos atributos que estn definidos
sobre el mismo dominio, Telfono y Fax.
Nombre del campo
NumOficina
Calle
Poblacin
Telfono
Fax

Descripcin
Nmero de la oficina
Nombre de la calle donde se ubica la oficina
Nombre de la poblaciones donde se ubica la oficina
Nmero de telfono de la oficina
Nmero de fax de la oficina

Definicin
3 caracteres
25 caracteres
25 caracteres
11 caracteres
11 caracteres

Tabla N 3.1 Dominio de valores de la relacin OFICINA.

Fuente: El autor, 2009.

El concepto de dominio es importante porque permite que el usuario defina, en un lugar

comn, el significado y la fuente de los valores que los atributos pueden tomar. Esto hace que
haya ms informacin disponible para el sistema cuando ste va a ejecutar una operacin
relacional, de modo que las operaciones que son semnticamente incorrectas, se pueden
evitar. Por ejemplo, no tiene sentido comparar el nombre de una calle con un nmero de
telfono, aunque los dos atributos sean cadenas de caracteres. Sin embargo, el importe
mensual del alquiler de un inmueble no estar definido sobre el mismo dominio que el nmero

de meses que dura el alquiler, pero s tiene sentido multiplicar los valores de ambos dominios
para averiguar el importe total al que asciende el alquiler. Los SMBD relacionales no ofrecen
un soporte completo de los dominios ya que su implementacin es extremadamente compleja.
Una tupla es una fila de una relacin. Los elementos de una relacin son las tuplas o
filas de la tabla. En la relacin OFICINA,, figura 3.1, existen cuatro tuplas, cada una tiene seis
valores, uno para cada atributo. Las tuplas de una relacin no siguen ningn orden.
El grado de una relacin es el nmero de campos que contiene
contiene. La relacin OFICINA
de la figura 3.1 es de gra
grado
do cinco porque tiene cinco atributos. Esto quiere decir que cada fila
de la tabla es una tupla con cinco valores. El grado de una relacin no cambia con frecuencia.
La cardinalidad de una relacin es el nmero de tuplas que contiene. Ya que en las
relaciones se van insertando y borrando tuplas a menudo, la cardinalidad de las mismas vara
constantemente. La relacin OFICINA, figura 3.1, es de cardinalidad cuatro.

3.3.1.1 Propiedades de las relaciones.

Cada relacin tiene un nombr

nombre
e y ste es distinto del nombre de todas las dems.
Los valores de los atributos son atmicos: en cada tupla, cada atributo toma un solo
valor. De ser as, se dice que la relacin estn normalizadas.
No hay dos atributos, dentro de una misma relacin, que
que se llamen igual.
El orden de los atributos no importa: los atributos no estn ordenados.
Cada tupla es distinta de las dems: no hay tuplas duplicadas.
El orden de las tuplas no importa: las tuplas no estn ordenadas.

3.3.1.2 Clave Primaria de las relaciones.

Ya que en una relacin no hay tuplas repetidas, stas se pueden distinguir unas de otras,
es decir, se pueden identificar de modo nico. La forma de identificarlas es mediante los
valores de sus atributos.

Una superclave es un atributo o un conjunto de atributos que identifican de modo

nico las tuplas de una relacin.

Una clave candidata es una superclave en la que ninguno de sus subconjuntos es

una superclave de la relacin. El atributo o conjunto de atributos
de la relacin
es una clave
lave candidata para
si y slo si satisface las siguientes propiedades:
Unicidad: nunca hay dos tuplas en la relacin
con el mismo valor de
.
Irreducibilidad (minimalidad): ningn subconjunto de
tiene la propiedad de
unicidad, es decir, no se pueden
pueden eliminar componentes de
sin destruir la
unicidad.

Cuando una clave candidata est formada por ms de un atributo, se dice que es una
clave compuesta.. Una relacin puede tener varias claves candidatas. Por ejemplo, en la
relacin OFICINA de la figura 3.1, el atributo Poblacin no es una clave candidata ya que
puede haber varias oficinas en una misma poblacin. Sin embargo, ya que la empresa asigna

un cdigo nico a cada oficina, el atributo NumOficina s es una clave candidata de la relacin
OFICINA. Tambin son claves candidatas de esta relacin los atributos Telfono y Fax.
En una base de datos de Inmobiliaria hay una relacin denominada VISITA, la cual se
muestra a continuacin, figura 3.3, que contiene informacin sobre las visitas que los clientes
han realizado a los inmuebles. Esta relacin contiene el nmero del cliente Qnum, el nmero
del inmueble Inum, la fecha de la visita Fecha, ID del empleado que efectu la visita
IDEmpleado y un Comentario opcional. Para un determinado nmero de cliente Qnum, se
pueden encontrar varias visitas a varios inmuebles. Del mismo modo, dado un nmero de
inmueble Inum, puede que haya varios clientes que lo hayan visitado. Por lo tanto, el atributo
Qnum no es una clave candidata para la relacin VISITA, como tampoco lo es el atributo
Inum. Sin embargo, la combinacin de los dos atributos s identifica a una sola tupla, por lo
que los dos juntos son una clave candidata de VISITA. Si se desea considerar la posibilidad
de que un mismo cliente pueda visitar un mismo inmueble en varias ocasiones, habra que
incluir el atributo Fecha para identificar las tuplas de modo nico (aunque ste no es el caso
de la empresa Inmobiliaria del ejemplo).
Qnum

Inum

Fecha

IDEmpleado

Comentario

Q76

IA14

12/03/1999

1182

Muy amplia y bien ubicada

Q74

IG40

30/11/1999

1285

Falta pintura a las paredes

Q62

IG36

25/10/1998

1182

Grandes espacios

Q74

IG36

14/08/1998

5682

Muy hermosa

Tabla N 3.2 Relacin VISITA de la base de datos Inmobiliaria.

Fuente: El autor, 2009.

El nico modo de identificar las claves candidatas es conociendo el significado real de los
atributos, ya que esto permite saber si es posible que aparezcan duplicados. Slo usando esta
informacin semntica se puede saber con certeza si un conjunto de atributos forman una
clave candidata.

La clave primaria de una relacin es aquella clave candidata que se escoge para
identificar sus tuplas de modo nico. Ya que una relacin no tiene tuplas duplicadas,
siempre hay una clave candidata y, por lo tanto, la relacin siempre tiene clave
primaria. En el peor caso, la clave primaria estar formada por todos los atributos de la
relacin, pero normalmente habr un pequeo subconjunto de los atributos que haga
esta funcin.

Las claves candidatas que no son escogidas como clave primaria son denominadas
claves alternativas. Por ejemplo, la clave primaria de la relacin OFICINA, figura 3.1,
es el atributo NumOficina, siendo Telfono y Fax dos claves alternativas. En la relacin
VISITA, figura 3.3, slo hay una clave candidata formada por los atributos Qnum e
Inum, por lo que esta clave candidata es la clave primaria.

3.3.1.3 Clave Fornea o Ajena de las relaciones.

Una clave fornea es un atributo o un conjunto de atributos de una relacin cuyos
valores coinciden con los valores de la clave primaria de alguna otra relacin (puede ser la
misma). Las claves ajenas representan relaciones entre datos. El atributo IDEmpleado de

VISITA, figura 3.3, es una clave ajena o fornea cuyos valores hacen referencia al atributo
IDEmpleado, clave primaria de la relacin EMPLEADO, figura 3.4.
IDEmplea
do

Nombre

Apellido

Cargo

Salario

1182

Pedro

Prez

Asistente

958.00

1285

Juan

Lpez

Jefe de Inmuebles

2458,45

2586

Mara

Prez

Administrador

3586,12

5682

Ana

Marchan

Asistente

1024,00

Tabla N 3.3 Relacin EMPLEADO de la base de datos Inmobiliaria.

Fuente: El autor, 2009.

En el mbito de las bases de datos relacionales, una clave fornea es una restriccin
referencial entre dos relaciones. La clave fornea establece que un grupo de atributos, en una
relacin, hace referencia a otro grupo de atributos, en otra. La primera relacin se denomina
referenciante (relacin EMPLEADO), mientras que la segunda, referenciada (relacin VISITA).
Los atributos que son clave fornea en la relacin referenciante deben ser clave primaria
o clave candidata en la relacin referenciada. Implementar una clave fornea establece que
ciertos atributos de la relacin referenciante slo podrn admitir elementos que existan
previamente en determinados atributos de la relacin referenciada.
La clave fornea es, entonces, una caracterstica importante en una base de datos. Su
utilizacin impropia puede generar problemas. Su principal objetivo es mantener la integridad
de la informacin almacenada.
Una base de datos relacional es un conjunto de relaciones normalizadas. Para
representar el esquema de una base de datos relacional se debe dar el nombre de sus
relaciones, los atributos de stas, los dominios sobre los que se definen estos
atributos, las claves primarias y las claves ajenas.
3.4 Integridad de Datos.
Una vez definida la estructura de datos del modelo relacional, se pasa a estudiar las
reglas de integridad que los datos almacenados en dicha estructura deben cumplir para
garantizar que son correctos.
Al definir cada atributo sobre un dominio se impone una restriccin sobre el conjunto de
valores permitidos para cada atributo. A este tipo de restricciones se les denomina
restricciones de dominios. Hay adems dos reglas de integridad muy importantes que son
restricciones que se deben cumplir en todas las bases de datos relacionales y en todos sus
estados o instancias (las reglas se deben cumplir todo el tiempo). Estas reglas son la regla de
integridad de entidades y la regla de integridad referencial.
Una base de datos que no cumpla con alguna de estas dos reglas, se dice que la base
de datos est en estado ilegal; si cumple con ambas, estar en estado legal. Antes de definir
ambas reglas, es preciso conocer el concepto de valor nulo.
Qu es un valor Nulo?

Cuando en una tupla un atributo es desconocido, se dice que es nulo. Un nulo no

representa el valor cero ni la cadena vaca, stos son valores que tienen significado. El nulo
implica ausencia de informacin, bien porque al insertar la tupla se desconoca el valor del
atributo, o bien porque para dicha tupla el atributo no tiene sentido.
Ya que los nulos no son valores, deben tratarse de modo diferente, lo que causa
problemas de implementacin. De hecho, no todos los SMBD relacionales soportan los nulos.

3.4.1

Regla de Integridad de Entidades.

La primera regla de integridad se aplica a las claves primarias de las relaciones base:
ninguno de los atributos que componen la clave primaria puede ser nulo.
Por definicin, una clave primaria es un identificador irreducible que se utiliza para
identificar de modo nico las tuplas. Irreducible significa que ningn subconjunto de la clave
primaria sirve para identificar las tuplas de modo nico. Si se permite que parte de la clave
primaria sea nula, se est diciendo que no todos sus atributos son necesarios para distinguir
las tuplas, con lo que se contradice la irreducibilidad.
Ntese que esta regla slo se aplica a las relaciones base y a las claves primarias, no a
las claves alternativas.

3.4.2 Regla de Integridad Referencial

La segunda regla de integridad se aplica a las claves ajenas: si en una relacin hay
alguna clave ajena, sus valores deben coincidir con valores de la clave primaria a la que hace
referencia, o bien, deben ser completamente nulos.
La regla de integridad referencial se enmarca en trminos de estados de la base de
datos: indica lo que es un estado ilegal, pero no dice cmo puede evitarse. La cuestin es
qu hacer si estando en un estado legal, llega una peticin para realizar una operacin que
conduce a un estado ilegal? Existen dos opciones: rechazar la operacin, o bien aceptar la
operacin y realizar operaciones adicionales compensatorias que conduzcan a un estado
legal.
Por lo tanto, para cada clave ajena de la base de datos habr que contestar a tres
preguntas:

Regla de los nulos: Tiene sentido que la clave ajena acepte nulos?
Regla de borrado: Qu ocurre si se intenta borrar la tupla referenciada por la clave
ajena?
o Restringir: no se permite borrar la tupla referenciada.
o Propagar: se borra la tupla referenciada y se propaga el borrado a las tuplas
que la referencian mediante la clave ajena.
o Anular: se borra la tupla referenciada y las tuplas que la referenciaban ponen a
nulo la clave ajena (slo si acepta nulos).
Regla de modificacin: Qu ocurre si se intenta modificar el valor de la clave primaria
de la tupla referenciada por la clave ajena?
o Restringir: no se permite modificar el valor de la clave primaria de la tupla
referenciada.

Propagar: se modifica el valor de la clave primaria de la tupla referenciada y se

propaga la modificacin a las tuplas que la referencian mediante la clave
ajena.
Anular: se modifica la tupla referenciada y las tuplas que la referenciaban
ponen a nulo la clave ajena (slo si acepta nulos).

3.4.3 Reglas de negocio.

Adems de las dos reglas de integridad anteriores, los usuarios o los administradores de
la base de datos pueden imponer ciertas restricciones especficas sobre los datos,
denominadas reglas de negocio. Por ejemplo, si en una oficina de la empresa inmobiliaria
slo puede tener hasta veinte empleados, el SMBD debe dar la posibilidad al usuario de
definir una regla al respecto y debe hacerla respetar. En este caso, no debera permitir
ingresar un nuevo empleado en una oficina que ya tiene los veinte permitidos.
Hoy en da an existen SMBD relacionales que no permiten definir este tipo de
restricciones ni las hacen respetar.

3.5 Manejo de Datos.

La tercera parte de un modelo de datos es la de la manipulacin. Son varios los
lenguajes utilizados por los SMBD relacionales para manejar las relaciones. Algunos de ellos
son procedurales, lo que quiere decir que el usuario dice al sistema exactamente cmo debe
manipular los datos. Otros son no procedurales, que significa que el usuario dice qu datos
necesita, en lugar de decir cmo deben obtenerse.
En este apartado se presentan el lgebra relacional y el clculo relacional, definidos por
Codd como la base de los lenguajes relacionales. Se puede decir que el lgebra es un
lenguaje procedural (de alto nivel), mientras que el clculo relacional es un lenguaje no
procedural. Sin embargo, ambos lenguajes son equivalentes: para cada expresin del lgebra,
se puede encontrar una expresin equivalente en el clculo, y viceversa.
El lgebra relacional (o el clculo relacional) se utilizan para medir la potencia de los
lenguajes relacionales. Si un lenguaje permite obtener cualquier relacin que se pueda derivar
mediante el lgebra relacional, se dice que es relacionalmente completo. La mayora de los
lenguajes relacionales son relacionalmente completos, pero tienen ms potencia que el
lgebra o el clculo porque se les han aadido operadores especiales.
Tanto el lgebra como el clculo son lenguajes formales no muy amigables. Pero su
estudio sirve para ilustrar las operaciones bsicas que todo lenguaje de manejo datos debe
ofrecer. Estos lenguajes, han sido la base para otros lenguajes relacionales de manejo de
datos de ms alto nivel, como el SQL.
La Unidad N IV estudia el Lenguajes SQL, como el lenguaje a utilizar para realizar el
manejo de la base de datos.

3.5.1 Vistas

En la arquitectura de tres niveles, estudiada en la Unidad I figura N 1.3, se describe una

vista externa como la estructura de la base de datos tal y como la ve un usuario en particular.
En el modelo relacional, el trmino vista tiene un significado un tanto diferente. En lugar de
ser todo el esquema externo de un usuario, una vista es una relacin virtual, una relacin que
en realidad no existe como tal.
Una vista se puede construir realizando operaciones como las del lgebra relacional:
restricciones, proyecciones, concatenaciones, etc. a partir de las relaciones base de la base
de datos. Las relaciones base son aquellas que forman parte directa de la base de datos, las
que se encuentran almacenadas fsicamente. Un esquema externo puede tener tanto
relaciones base como vistas derivadas de las relaciones base de la base de datos.
Una vista es el resultado dinmico de una o varias operaciones relacionales realizadas
sobre las relaciones base. Una vista es una relacin virtual que se produce cuando un usuario
la consulta. Al usuario le parece que la vista es una relacin que existe y la puede manipular
como si se tratara de una relacin base, pero la vista no est almacenada fsicamente. El
contenido de una vista est definido como una consulta sobre una o varias relaciones base.
Cualquier operacin que se realice sobre la vista se traduce automticamente a operaciones
sobre las relaciones de las que se deriva.
Las vistas son dinmicas porque los cambios que se realizan sobre las tablas base que
afectan a una vista se reflejan inmediatamente sobre ella. Cuando un usuario realiza un
cambio sobre la vista (no todo tipo de cambios estn permitidos), este cambio se realiza sobre
las relaciones de las que se deriva. Las vistas son tiles por varias razones:

Proporcionan un poderoso mecanismo de seguridad, ocultando partes de la base de

datos a ciertos usuarios. El usuario no sabr que existen aquellos atributos que se han
omitido al definir una vista.

Permiten que los usuarios accedan a los datos en el formato que ellos desean o
necesitan, de modo que los mismos datos pueden ser vistos con formatos distintos por
distintos usuarios.

Se pueden simplificar operaciones sobre las relaciones base que son complejas. Por
ejemplo, se puede definir una vista como la concatenacin de dos relaciones. El
usuario puede hacer restricciones y proyecciones sobre la vista, que el SMBD
traducir en las operaciones equivalentes sobre la concatenacin.

Se puede utilizar una vista para ofrecer un esquema externo a un usuario de modo que
ste lo encuentre familiar. Por ejemplo:

Un usuario puede necesitar los datos de los Empleados junto con los de las Visitas.
Esta vista se crea haciendo una concatenacin de las relaciones VISITA y
EMPLEADO, y proyectando sobre los atributos que se desee mantener, ver figura
siguiente.
Qnum
Q76
Q74
Q62
Q74

Inum
IA14
IG40
IG36
IG36

IDEmpleado
1182
1285
1182
5682

Nombre
Pedro
Juan
Pedro
Ana

Apellido
Prez
Lpez
Prez
Marchan

Comentario
Muy amplia y bien ubicada
Falta pintura a las paredes
Grandes espacios
Muy hermosa

Tabla N 3.4 Vista de las relaciones EMPLEADO y VISITA de la base de datos Inmobiliaria.
Fuente: El autor, 2009.

Otro usuario puede que necesite ver los datos de los empleados sin ver el salario.
Para este usuario se realiza una proyeccin para crear una vista sin el atributo salario.
IDEmpleado
1182
1285
2586
5682

Nombre
Pedro
Juan
Mara
Ana

Apellido
Prez
Lpez
Prez
Marchan

Cargo
Asistente
Jefe de Inmuebles
Administrador
Asistente

Tabla N 3.5 Vista de la relacin EMPLEADO de la base de datos Inmobiliaria.

Fuente: El autor, 2009.

Los atributos se pueden renombrar, de modo que cada usuario los vea del modo en
que est acostumbrado. Tambin se puede cambiar el orden en que se visualizan las
columnas.

IDEmpleado
1182
1285
2586
5682

ApellidoEmpleado
Prez
Lpez
Prez
Marchan

NombreEmpleado
Pedro
Juan
Mara
Ana

CargoActual
Asistente
Jefe de Inmuebles
Administrador
Asistente

Tabla N 3.6 Vista de la relacin EMPLEADO de la base de datos Inmobiliaria.

Fuente: El autor, 2009.

El Cliente N Q74 de la base de datos Inmobiliaria, relacin VISITA de la figura 3.3,

quiere ver que Inmuebles ella ha visitado. En este caso, se debe hacer una restriccin
para que slo se vea el subconjunto horizontal deseado de la relacin VISITA.
Qn
um
Q74
Q74

Inum

Fecha

IDEmpleado

IG40
IG36

30/11/1999
14/08/1998

1285
5682

Comentario
Falta pintura a las paredes
Muy hermosa

Tabla N 3.7 Vista de la relacin VISITA de la base de datos Inmobiliaria.

Fuente: El autor, 2009.

Como se pudo observar, las vistas proporcionan independencia de datos a nivel lgico,
que tambin se da cuando se reorganiza el nivel conceptual. Si se aade un atributo a una
relacin, los usuarios no se percatan de su existencia si sus vistas no lo incluyen. Si una
relacin existente se reorganiza o se divide en varias relaciones, se pueden crear vistas para
que los usuarios la sigan viendo como al principio.
Cuando se actualiza una relacin base, el cambio se refleja automticamente en todas
las vistas que la referencian. Del mismo modo, si se actualiza una vista, las relaciones base de
las que se deriva deberan reflejar el cambio. Sin embargo, hay algunas restricciones respecto

a los tipos de modificaciones que se pueden realizar sobre las vistas. A continuacin, se
resumen las condiciones bajo las cuales la mayora de los sistemas determinan si se permite
realizar una actualizacin:

Se permiten las actualizaciones de vistas que se definen mediante una consulta simple
sobre una sola relacin base y que contienen la clave primaria de la relacin base.

No se permiten las actualizaciones de vistas que se definen sobre varias relaciones

base.

No se permiten las actualizaciones de vistas definidas con operaciones de

agrupamiento (GROUPBY).

3.6. Conversin del Modelo Conceptual al Modelo Lgico-Relacional.

Una vez obtenido el modelo conceptual de la base de datos, a travs de la construccin
del diagrama Entidad-Relacin o diagrama Entidad-Relacin Extendido, se procede a la
construccin del modelo lgico de la base de datos (segunda fase en el diseo de bases de
datos). Este modelo lgico va a depender del modelo de datos seleccionados, en nuestro
caso el modelo de datos es el relacional; el cual se acaba de estudiar.
En esta etapa se obtiene un conjunto de relaciones (tablas) que representen los datos de
inters. Este conjunto de relaciones obtenidas, posteriormente se valida mediante la
normalizacin, tcnica que se estudia al final de esta unidad, en el punto 3.8.
Primeramente, se construye el modelo lgico relacional eliminando del diagrama E-R las
estructuras de datos que no se pueden implementar de manera directa sobre el modelo
relacional.

3.6.1 Convertir el diagrama Entidad-Relacin al modelo lgico-relacional.

En este paso, se eliminan del modelo conceptual (diagrama E-R) las estructuras de datos
que los sistemas relacionales no modelan directamente:
1. Eliminar las relaciones con cardinalidad mucho a mucho (ver figura 3.2a), sustituyendo
cada una de ellas por una nueva entidad intermedia y dos relaciones con cardinalidad uno a
muchos desde esta nueva entidad con las entidades originales, figura 3.2b. La nueva entidad
ser dbil, ya que sus ocurrencias dependen de la existencia de ocurrencias en las entidades
originales. Ejemplo en la siguiente figura:

10

Prstamo

Estudiante

a) Relacin con cardinalidad mucho a mucho.

Faltan los atributos.

Libro

Esta

Prstamo

Realiza

Estudiante

b) Entidad dbil con dos relaciones uno a mucho.

Faltan los atributos.

Figura N 3.2 Sustitucin de una relacin mucho a mucho por una entidad dbil.
Fuente: El autor, 2009.

2. Eliminar las relaciones ternarias (ver figura 3.3a), sustituyendo cada una de ellas por una
nueva entidad intermedia (dbil) que se relaciona con cada una de las entidades originales,
ver figura 3.3b. La cardinalidad de estas nuevas relaciones binarias depender de su
significado. Ejemplo en la siguiente figura:
Cliente

Presta

Consultor
a)

Servicio

Relacin Ternaria. Faltan los atributos.

Cliente

Consultor

Servicio

Cliente
Consultor
Servicio

b) Entidad dbil con tres relaciones uno a mucho. Faltan los atributos.

Figura N 3.3 Sustitucin de una relacin ternaria por una entidad dbil.
Fuente: El autor, 2009.

3. Eliminar las relaciones recursivas (ver figura 3.4a), sustituyendo cada una de ellas por
una nueva entidad (dbil) y una relacin binarias con la entidad original. La cardinalidad de
estas relaciones depender de su significado. Ejemplo figura siguiente:
Empleado

Supervisa
Supervisor

a) Relacin recursiva. Faltan los atributos.

11

Supervisa

Empleado
b)

Supervisor

Entidad dbil con una relacin uno a mucho. Faltan los atributos.

Figura N 3.4 Sustitucin de una relacin recursiva por una entidad dbil.
Fuente: El autor, 2009.

4. Eliminar las relaciones con atributos (ver figura 3.5a), sustituyendo cada una de ellas
por una nueva entidad (dbil) y las relaciones binarias correspondientes de esta nueva entidad
con las entidades originales, figura 3.5b. La cardinalidad de estas relaciones
rela
depender del
tipo de la relacin original y de su significado. Ejemplo en la figura siguiente:

a) Relacin con atributos.

Nombre

CURP

Fecha

Direccin

Tipo Cta.

Cliente

No_Cta

Saldo

Cuenta

ClienteCta

b) Entidad dbil con dos relaciones binarias.

Figura N 3.5 Sustitucin de una relacin con atributos por una entidad dbil.
Fuente: El autor, 2009.

5. Eliminar los atributos multievaluados (ver figura 3.6a), sustituyendo cada uno de ellos
por una nueva entidad (dbil) y una relacin binaria de uno a muchos con la entidad original,
ver figura 3.6b. Ejemplo figura siguiente.

cdula

Nombre

Telfonos

Cliente
a) Entidad con atributo multivaluado.
Cdula

Nombre

Cliente

Nmero

Telfonos
Cliente

b) Entidad dbil con una relacin binaria.

Figura N 3.6 Sustitucin de un atributo multivaluado por una entidad dbil.

Fuente: El autor, 2009.

12

3.6.2 Derivar el conjunto de relaciones (tablas).

En este paso, se obtiene el conjunto de relaciones (tablas) para el esquema lgico. Cada
relacin de la base de datos tendr un nombre, y el nombre de sus atributos. El atributo o los
atributos que forman la clave primaria se subrayan. Las claves ajenas o forneas, mecanismo
que se utiliza para representar las relaciones entre entidades en el modelo relacional, se
especifican aparte indicando la relacin (tabla) a la que hacen referencia.
A continuacin, se describe cmo las relaciones (tablas) del modelo relacional
representan las entidades y relaciones que aparecer en los esquemas lgicos (diagrama E-R).
1. Entidades fuertes. Crear una relacin (tabla) para cada entidad fuerte del diagrama E-R
que incluya todos los atributos simples de la entidad. De los atributos compuestos, incluir en la
relacin slo sus componentes, ver figura 3.7.
Cada uno de los identificadores de la entidad ser una clave candidata de la relacin
(tabla). De entre las claves candidatas hay que escoger la clave primaria; el resto sern claves
alternativas. Para escoger la clave primaria entre las claves candidatas se pueden seguir
estas indicaciones:

Escoger la clave candidata que tenga menos atributos.

Escoger la clave candidata cuyos valores no tengan probabilidad de cambiar en el futuro.
Escoger la clave candidata cuyos valores no tengan probabilidad de perder la unicidad en
el futuro.
Escoger la clave candidata con el mnimo nmero de caracteres (si es de tipo texto).
Escoger la clave candidata ms fcil de utilizar desde el punto de vista de los usuarios.
Avenida
N_Casa

Tabla: Cliente

Calle
cdula

Nombre

Nmero

Direccin

Cliente

Cdula

Nombre

Avenida

Calle

N_Casa

Telfonos
Cliente
Entidad Dbil

Entidad Fuerte

Figura 3.7 Conversin de una entidad fuerte en una tabla de la base de datos.
Fuente: El autor, 2009.

2. Entidades dbiles. Para cada entidad dbil del diagrama E-R, crear una relacin (tabla)
incluyendo todos sus atributos simples. De los atributos compuestos incluir slo sus
componentes. Aadir a la relacin (tabla) una clave ajena o fornea. Para ello, se incluye la
clave primaria de la relacin (tabla) que representa a la entidad fuerte o padre, en la nueva
relacin creada para la entidad dbil, ver figura 3.8. Subrayar la clave primaria, en este caso
se trata de una clave primaria compuesta.
Tabla: TelfonosCliente

Avenida
N_Casa
Calle
cdula

Nombre

Direccin

Cliente

Entidad Fuerte

Nmero

Telfonos
Cliente
Entidad Dbil

13

Cdula

Nmero

Figura 3.8 Conversin de una entidad dbil en una tabla de la base de datos.
Fuente: El autor, 2009.

3. Relaciones binarias de uno a uno. Para cada relacin binaria de uno a uno del diagrama
E-R, se debe incluir los atributos candidatos de la entidad padre en la relacin (tabla) que
representa a la entidad hijo, para actuar como una clave ajena. La entidad hijo es la que
participa de forma total (obligatoria) en la relacin, mientras que la entidad padre es la que
participa de forma parcial (opcional). Si las dos entidades participan de forma total o parcial en
la relacin uno a uno, la eleccin de padre e hijo es arbitraria. Adems, en caso de que ambas
entidades participen de forma total en la relacin, se tiene la opcin de integrar las dos
entidades en una sola relacin (tabla). Esto se suele hacer si una de las entidades no participa
en ninguna otra relacin. Ver figura 3.9.

Entidad Hijo

Entidad Padre

Tabla: Presidente
Nombre

Tabla: Pas

Direccin

Partido

NomPais

Nombre

Habitantes

Dimensin

Figura 3.9 Conversin de una relacin binaria de uno a uno al modelo relacional.
Fuente: El autor, 2009.

4. Relaciones binarias de uno a muchos. Como en las relaciones binarias de uno a uno, se
incluyen los atributos de la clave primaria de la entidad padre en la relacin (tabla) que
representa a la entidad hijo, para actuar como una clave ajena. Pero ahora, la entidad padre
es la parte del muchos'' (cada padre tiene muchos hijos), mientras que la entidad hijo es la
parte del uno'' (cada hijo tiene un solo padre). Ver figura siguiente.

cdula

Nombre

Empleado
Entidad Fuerte

Cargo

Cdula

Nombre
Edad
Hijos

Entidad Dbil

14

Tabla: Empleado
Cdula

Nombre

Tabla: Hijos
Cargo

CdulaPadre

Cdula

Nombre

Edad

Figura 3.10 Conversin de una relacin binaria de uno a uno al modelo relacional.
Fuente: El autor, 2009.

3.6.3 Paso de ERE a Modelo Relacional.

El paso de ERE a modelo relacional es una extensin de las normas del paso EntidadEntidad
Relacin. Las reglas complementarias hacen referencia a los elementos propios del ERE y
son las siguientes:
Existen cuatro opciones para realizar el paso a modelo relacional de las relaciones
Superclase/Subclase correspondientes a Especializaciones o Generalizaciones.
Opcin A: Crear una relacin (tabla) para la superclase, con sus atributos correspondientes y
una relacin (tabla) para
para cada subclase con sus atributos ms la clave primaria de la
superclase. Esta opcin es vlida para especializaciones parciales o totales y con restriccin
de desunin o solapamiento. Ver figura 3.11.

EMPLEADO
DNI

Pila

Ape1

SECRETARIA
DNI

Veloc

Ape2

Fecha

Dir

tipoTrabajo

TECNICO
DNI

INGENIERO
Nivel

DNI

Tipo

Figura 3.11 Conversin de una relacin Superclase/Subclase al modelo relacional. Opcin A.

Fuente: El autor, 2009.

Opcin B: Crear para cada subclase una relacin con los atributos de la superclase ms los
atributos propios, donde la clave primaria ser la de la superclase. Esta opcin slo es vlida
para las especializaciones con restriccin de totalidad y desunin ya que, si una ocurrencia de

15

la superclase no pertenece a ninguna de las subclases, se pierde; y si pertenece a ms de

una, sus datos aparecen de forma redundante en ms de una relacin. Adems tiene el
inconveniente de que al buscar una ocurrencia cualquiera de la superclase,
superclase, tendremos que
recorrer todas las relaciones. Ver figura siguiente:

COCHE
Nvehiculo

Matrcula

Precio

V.max

Npas

CAMION
Nvehiculo

Matrcula

Precio

Nejes

Peso

Figura 3.12 Conversin de una relacin Superclase/Subclase al modelo relacional. Opcin B.

Fuente: El autor, 2009.

Opcin C: Crear una sola relacin con todos los atributos de la superclase y las subclases
ms un atributo T que indica la subclase a la que la tupla pertenece. Esto corresponde a una
especializacin de clases desunidas y puede generar muchos valores nulos. Esta opcin no
es apropiada cuando se utilizan muchos atributos de definicin para la especializacin. Si se
utilizan pocos atributos de especificacin,
especificacin, esta opcin es preferible a las opciones A y B, ya
que, no requiere la utilizacin de JOIN para la conformacin de la superclase completa. Ver
figura:

PERSONA
DNI Nombre

Sexo

Dir

Fecha-n

Sueldo

especialidad

TipoPersona

Figura 3.13 Conversin de una relacin Superclase/Subclase al modelo relacional. Opcin C

Fuente: El autor, 2009.

16

Opcin D: Crear una sola tabla con todos los atributos de la superclase ms atributos de las
subclases, mas unos atributos Ti cuyo valor lgico nos indicar a qu subclase pertenece la
tupla. Esta opcin corresponde una especializacin con solapamiento. Ver figura siguiente:

PERSONA
DNI

Nombre

Dir

Fecha_n

Sexo

Empleado

Sueldo

Estudiante

Especialidad

Figura 3.14 Conversin de una relacin Superclase/Subclase al modelo relacional. Opcin D

Fuente: El autor, 2009.

3.7 Normalizacin de Bases de Datos.

El proceso de Normalizacin de Bases de Datos consiste en aplicar una serie de reglas
a las relaciones obtenidas tras el paso del diagrama E-R
E al modelo relacional
relacional. Estas reglas
sirven para ayudar a los diseadores de bases de datos a desarrollar un esquema que
minimice los problemas de lgica.
La normalizacin es el proceso mediante el cual se ttransforman
ransforman datos complejos a un
conjunto de estructuras de datos ms pequeas, que adems de ser ms simples y ms
estables, son ms fciles de mantener. La normalizacin se adopt porque el viejo estilo de
poner todos los datos en un solo lugar, como un archivo
archivo o una relacin de la base de datos,
era ineficiente y conduca a errores de lgica cuando se trataban de manipular los datos.
Las bases de datos relacionales se normalizan para:

Evitar la redundancia de los datos.

Evitar problemas de actualizacin de los datos en las relaciones.
Proteger la integridad de los datos.

El proceso de normalizacin tiene un nombre y una serie de reglas para cada fase. Esto
puede parecer un poco confuso al principio, pero poco a poco se va entendiendo el proceso,
as como las razones para hacerlo de esta manera.

17

3.7.1 Grados de normalizacin.

Existen bsicamente tres niveles de normalizacin: Primera Forma Normal (1FN),
Segunda Forma Normal (2FN) y Tercera Forma Normal (3FN). Cada una de estas formas
tiene sus propias reglas. Cuando una base de datos se conforma a un nivel, se considera
normalizada a esa forma de normalizacin. No siempre es una buena idea tener una base de
datos conformada en el nivel ms alto de normalizacin, puede llevar a un nivel de
complejidad que pudiera ser evitado si estuviera en un nivel ms bajo de normalizacin.
En la tabla siguiente se describe brevemente en que consiste cada una de las reglas, y
posteriormente se explican con ms detalle.
Regla

Descripcin

Primera Forma
Normal (1FN)

Incluye la eliminacin de todos los grupos repetidos.

Segunda Forma
Normal (2FN)

Asegura que todos los atributos (campos) que no son clave primaria sean
completamente dependientes de la clave primaria (llave).

Tercera Forma
Normal (3FN)

Elimina cualquier dependencia transitiva. Una dependencia transitiva es aquella

en la cual los atributos que no son clave primaria (llave) son dependientes de
otros atributos que tampoco son clave primaria.
Tabla N 3.8 Descripcin de las formas normales 1FN, 2FN y 3 FN.
Fuente: El autor, 2009.

3.7.2 Primera Forma Normal (1FN).

Una relacin est en Primera Forma Normal slo si cumple con las siguientes reglas:

Todos los atributos son atmicos. Un atributo es atmico si los elementos del dominio
son indivisibles, mnimos.
La relacin contiene una clave primaria.
La relacin no contiene atributos nulos.
Si no posee ciclos repetitivos.

A continuacin se explicar algunos trminos, citados anteriormente, a objeto de

entender cuando una relacin (tabla) no se encuentra en su 1FN.

1. Que son Ciclos o Grupos repetidos?

El siguiente ejemplo ilustra cmo un diseo de base de datos puede incorporar la
repeticin de grupos, en violacin de la 1FN.
Ejemplo 1: Dominios y valores.
Suponga que un diseador principiante desea guardar los nombres y los nmeros
telefnicos de los clientes. Procede a definir una relacin (tabla) cliente como sigue:
ID Cliente Nombre Apellido

Telfono

123

0293-55586025

Raquel

Prez

18

456

Jaime

Rengel

0281-55540359

789

Mara

Fernndez 0414-55508633

Tabla N 3.9 Tabla CLIENTE.

Fuente: El autor, 2009.

En este punto, el diseador se da cuenta que un requisito es guardar mltiples nmeros

telefnicos para algunos clientes, es decir el atributo o campo Telfono es multivaluado.
Razona que la manera ms simple de hacer esto es permitir que el campo "Telfono"
contenga ms de un valor en cualquier registro dado. Ver tabla siguiente.
ID Cliente Nombre Apellido

Telfono

123

Raquel

Prez

02935556025

456

Jaime

Rengel

02815554059
02815557700

789

Mara

Fernndez 04145550833

Tabla N 3.10 Tabla CLIENTE no Normalizada.

Fuente: El autor, 2009.

Asumiendo, sin embargo, que el campo "Telfono" posee un dominio de valores de 11

caracteres numricos de longitud y un formato de captura de datos igual a 99999999999, la
representacin de arriba no est en 1FN. La 1FN prohbe a un campo contener ms de un
valor de su dominio, es decir, el campo Telfono perdera su atomicidad.
Ejemplo 2: Grupos repetidos a travs de columnas
El diseador decide evitar esta restriccin definiendo mltiples columnas (atributos) del
nmero telefnico, resultando la siguiente tabla:
ID Cliente Nombre Apellido

Telfono 1

123

Raquel

Prez

02935556025

Telfono 2

456

Jaime

Rengel

02815554059 02815557700

789

Mara

Fernndez 04145550833

Telfono 3

Tabla N 3.11 Tabla CLIENTE con atributos repetidos.

Fuente: El autor, 2009.

Sin embargo, esta representacin hace uso de columnas que permiten valores nulos, y
por lo tanto no se conforman con la definicin de la 1FN. Incluso si se contempla la posibilidad
de columnas con valores nulos, el diseo no est en armona con el espritu de 1FN. Telfono
1, Telfono 2, y Telfono 3, comparten exactamente el mismo dominio y exactamente el
mismo significado; el dividir del nmero de telfono en tres encabezados es artificial y causa
problemas lgicos. Estos problemas incluyen:

Dificultad en hacer consultas a la relacin. Es difcil contestar preguntas tales como

"Qu clientes tienen el telfono X?" y "Qu pares de clientes comparten un nmero
de telfono?".

19

La imposibilidad de hacer cumplir la unicidad los enlaces Cliente-a-Telfono por medio

del SMBD. Al cliente 789 se le puede dar equivocadamente un valor para el Telfono 2
que es exactamente igual que el valor de su Telfono 1.

La restriccin de los nmeros de telfono por cliente a tres. Si viene un cliente con
cuatro nmeros de telfono, estamos obligados a guardar solamente tres y dejar el
cuarto sin guardar. Esto significa que el diseo de la base de datos est imponiendo
restricciones al proceso del negocio, en vez de (como idealmente debe ser el caso) al
revs.

Ejemplo 3: Repeticin de grupos dentro de columnas

El diseador puede, alternativamente, conservar una sola columna de nmero de
telfono, pero alterando su dominio, haciendo una cadena de suficiente longitud para
acomodar mltiples nmeros telefnicos, como se muestra continuacin:
ID Cliente Nombre Apellido

Telfono

123

Raquel

Prez

02935556025

456

Jaime

Rengel

02815554059, 0281557700

789

Mara

Fernndez 04145550833

Tabla N 3.12 Tabla CLIENTE con atributo Telfono no atmico.

Fuente: El autor, 2009.

ste es defendiblemente el peor diseo de todos, y otra vez no mantiene el espritu de la

1FN. El encabezado "Telfono" llega a ser semnticamente difuso, ya que ahora puede
representar, o un nmero de telfono, o una lista de nmeros de telfono, o de hecho
cualquier cosa. Una consulta como "Qu pares de clientes comparten un nmero telefnico?"
es virtualmente imposible de formular, dada la necesidad de proveerse de listas de nmeros
telefnicos as como nmeros telefnicos individuales. Con este diseo es imposibles definir
significativas restricciones en nmeros telefnicos. Adems, igual se estara limitando el
nmero de telfonos que podran guardarse para un cliente.
Un diseo conforme con 1FN.
Un diseo que est inequvocamente en 1FN hace uso de dos relaciones: una relacin
de cliente y una relacin de telfono del cliente, ver tablas respectivas.
ID Cliente Nombre Apellido
123

Raquel

Prez

456

Jaime

Rengel

789

Mara

Fernndez

Tabla N 3.13 Tablas CLIENTE Normalizada.

Fuente: El autor, 2009.

En este diseo no ocurren grupos repetidos de nmeros telefnicos. No se guardan

valores nulos. Tampoco limita el nmero de telfonos que se puede guardar de un mismo
cliente. Y se mantiene el dominio de valores del campo telfono a los 11 caracteres en el
formato 99999999999.
ID Cliente Telfono

20

123

02935556025

456

02815554059

456

02815557700

789

04145550833

Tabla N 3.14 Tablas TELEFONOCLIENTE Normalizada.

Fuente: El autor, 2009.

2. Qu es Atomicidad?
E.F. Codd, hace referencia al concepto de atomicidad e indica que "se requiere que los
valores sean atmicos con respecto al SMBD en los dominios en los que cada relacin es
definida". Codd define un valor atmico como uno que "no puede ser descompuesto en
pedazos ms pequeos por el SMBD (excepto ciertas funciones especiales)".
Hugh Darwen y Chris Date han sugerido que el concepto de Codd de un "valor atmico"
es ambiguo, y que esta ambigedad ha conducido a una extensa confusin sobre cmo debe
ser entendida la 1FN. En particular, la nocin de un "valor que no puede ser descompuesto"
es problemtica, pues parecera implicar que pocos, si algn, tipos de datos son atmicos:

Una cadena de caracteres parecera no ser atmica, ya que el SMBD tpicamente

proporciona operadores para descomponerla en subcadenas.

Una fecha parecera no ser atmica, ya que el SMBD proporciona tpicamente

operadores para descomponerla en los componentes da, mes, y ao.

Un nmero de punto decimal parecera no ser atmico, ya que el SMBD proporciona

tpicamente operadores para descomponerlo en componentes de nmeros enteros y
fraccionarios.

Date sugiere que "la nocin de atomicidad no tiene ningn significado absoluto": un valor
puede ser considerado atmico para algunos propsitos, pero puede ser considerado un
ensamblaje de elementos ms bsicos para otros propsitos. Si esta posicin es aceptada, la
1FN no puede ser definida con referencia a la atomicidad. Las columnas de cualquier tipo de
datos concebible (desde tipos de cadenas y tipos numricos hasta tipos de arreglos y tipos de
tabla) son entonces aceptables en una relacin 1FN - aunque quizs no siempre deseable.
Date discute que los atributos relacin-valor, por medio de los cuales un campo dentro de una
relacin puede contener una relacin, son tiles en casos raros.
3.7.3 Segunda Forma Normal (2FN).
Una relacin est en 2FN si est en 1FN y si los atributos que no forman parte de la
clave primaria dependen de ella en forma completa. Es decir que no existen dependencias
parciales.
La regla de la 2FN establece que todas las dependencias parciales se deben eliminar y
separar dentro de sus propias tablas. Una dependencia parcial es un trmino que describe a

21

aquellos datos que no dependen de la clave primaria de la relacin (tabla) para identificarlos.
Una vez alcanzado el nivel de la 2 Forma Normal, se controlan la mayora de los problemas de
lgica. Podemos insertar un registro sin un exceso de datos en la mayora de las tablas.

3.7.4 Tercera Forma Normal (3FN).

Una relacin se encuentra en 3FN si est en 2FN y cada atributo que no forma parte de
la clave primaria, depende directamente y no transitivamente, de la clave primaria.
Una relacin est normalizada en esta forma si todas las columnas que no son clave son
funcionalmente dependientes por completo de la clave primaria y no hay dependencias
transitivas. Una dependencia transitiva es aquella en la cual existen atributos que no son clave
primaria y dependen de otros atributos que tampoco son clave primaria.
Cuando las relaciones estn en la Tercera Forma Normal se previenen errores de lgica
cuando se insertan o borran registros. Cada atributo en una relacin est identificado de
manera nica por la clave primaria, y no debe haber datos repetidos. Esto provee un esquema
limpio y elegante, que es fcil de trabajar y expandir.
3.7.5 Ejemplo de un proceso de Normalizacin.
Para explicar con un ejemplo en que consiste el proceso de Normalizacin y cada una de
las reglas que esto implica, vamos a considerar los datos de la relacin RDENES, que sigue
a continuacin.
ID_ORDEN

FECHA

ID_CLIENTE

NOM_CLIENTE

ESTADO

NUM_ITEM

DESC_ITEM

CANT

PRECIO

2301

23/02/08

101

MARTI

SUCRE

3786

RED

35

2301

23/02/08

101

MARTI

SUCRE

4011

RAQUETA

65

2301

23/02/08

101

MARTI

SUCRE

9132

PAQ-3

4.75

2302

25/02/08

107

HERMAN

LARA

5794

PAQ-6

5.0

2303

27/02/08

110

MARIA

APURE

4011

RAQUETA

65

2303

27/02/08

110

MARIA

APURE

3141

FUNDA

10

Tabla N 3.15 Tablas ORDENES no Normalizada.

Fuente: El autor, 2009.

a.) Paso de una relacin a su 1FN.

Primeramente debemos examinar las tuplas de la relacin base, en nuestro caso la
relacin RDENES, a objeto de identificar si cumple con cada una de las reglas de la 1FN,
presentadas anteriormente en el punto 3.7.2.
Al examinar estas tuplas, se puede observar que existen valores repetidos en las
columnas ID_ORDEN, FECHA, ID_CLIENTE, NOM_CLIENTE y ESTADO para valores
diferentes de las columnas NUM_ITEM, DESC_ITEM, CANT y PRECIO. La 1FN prohbe los
grupos repetidos, por lo tanto tenemos que llevar la relacin RDENES a la 1FN. Los pasos a
seguir son:

22

1. Tenemos que eliminar de la relacin ORDENES las columnas que estn causando la
los grupos repetidos de valores, es decir, las columnas NUM_ITEM, DESC_ITEM,
CANT y PRECIO.
2. Tenemos que crear una nueva relacin; la misma ha de tener la Clave Primaria (FK)
de la relacin base, es decir, la columna ID_ORDEN, y el grupo de columnas que
eliminamos en el paso anterior.
3. Posteriormente, definimos una Clave Primaria para la nueva relacin. Esta ser una
clave compuesta por la Clave Primaria de la relacin base y una de las columna
restantes. Se debe considerar cual de ellas es la ms adecuada.
Los registros quedan ahora conformados en dos relaciones; la relacin Base RDENES
y la nueva relacin ARTCULOS_ORDENES.

ID_ORDEN

FECHA

ID_CLIENTE

NOM_CLIENTE

ESTADO

2301

2/23/03

101

MARTI

SUCRE

2302

2/25/03

107

HERMAN

LARA

2303

2/27/03

110

MARIA

APURE

Tabla N 3.16 Tablas OREDENES en 1FN.

Fuente: El autor, 2009.

ID_ORDEN

NUM_ITEM

DESC_ITEM

CANT

PRECIO

2301

3786

RED

35

2301

4011

RAQUETA

65

2301

9132

PAQ-3

4.75

2302

5794

PAQ-6

5.0

2303

4011

RAQUETA

65

2303

3141

FUNDA

10

Tabla N 3.17 Tablas ARTICULOS_ORDENES en 1FN.

Fuente: El autor, 2009.

Si observamos nuevamente la relacin RDENES, podemos ver que:

No existen grupos repetitivos,

La relacin posee una clave primaria,
No contiene valores nulos,
Todos sus valores son atmicos

Se puede decir, entonces, que la relacin RDENES se encuentra en la 1FN, ya que

cumple con todas las reglas enumeradas en el punto 3.7.2.
Evaluamos si la nueva relacin ARTCULOS_ORDENES est en su 1FN. De no estar se
repite el proceso anterior para esta nueva relacin. De lo contrario seguimos con la 2FN. La
relacin ARTCULOS_ORDENES si est en su 1FN.

23

b.) Paso a la 2FN.

Una vez comprobada que las relaciones resultantes se encuentran en su 1FN,
procederemos a aplicar la 2FN, es decir, tenemos que eliminar cualquier columna no clave
primaria que no dependa de la clave primaria de la relacin. Los pasos a seguir son:

Determinar cules atributos que no son clave primaria no dependen de la clave

primaria de la relacin.

Eliminar esos atributos de la relacin base.

Crear una segunda relacin con esos atributos y lo(s) atributos(s) de la clave primaria
de la cual dependen.

La relacin RDENES est en 2FN. Cualquier valor nico de ID_ORDEN determina un

slo valor para cada columna. Por lo tanto, todas las columnas poseen dependencia funcional
completa con la llave primaria ID_ORDEN.
Por su parte, la relacin ARTCULOS_ORDENES no se encuentra en 2FN; ya que las
columnas PRECIO y DESC_ITEM son dependientes de la columna NUM_ITEM, pero no son
dependientes de ID_ORDEN, es decir, no existe dependencia funcional completa con el
campo clave, en este caso, ID_ODEN y NUM_ITEM; por lo tanto tenemos que llevar la relacin
ARTCULOS_ORDENES a su 2FN. Los pasos a seguir son:

1. Eliminar estas columnas (PRECIO y DESC_ITEM) de la relacin

ARTCULOS_ORDENES.
2. Crear una nueva relacin, es este caso la relacin ARTCULOS, con dichas columnas
y la columna de la clave primaria de la que dependen.
3. Esa columna representar para la nueva relacin la clave primaria.
Las relaciones quedan ahora de la siguiente manera.

ID_ORDEN

NUM_ITEM

CANT

NUM_ITEM

DESC_ITEM

PRECIO

2300

3786

3786

RED

35

2301

4011

4011

RAQUETA

65

2301

9132

9132

PAQ-3

4.75

2302

5794

5794

PAQ-6

5.0

2303

4011

4011

RAQUETA

65

2303

3141

3141

FUNDA

10

Tabla N 3.18 Tablas ARTICULOS_ORDENES y ARTICULOS Normalizadas.

Fuente: El autor, 2009.

c.) Paso a la 3FN.

24

La tercera forma normal nos dice que tenemos que eliminar cualquier columna no llave
que sea dependiente de otra columna no llave. Los pasos a seguir son:

Determinar las columnas que son dependientes de otra columna no llave.

Eliminar esas columnas de la relacin base.
Crear una segunda relacin con esas columnas y con la columna no llave de la cual
son dependientes.

Al observar las relaciones que se han creado, nos damos cuenta que tanto la relacin
Artculos, como la relacin Artculos _ rdenes se encuentran en 3FN. Sin embargo la
relacin rdenes no lo est, ya que NOM_CLIENTE y ESTADO son dependientes de
ID_CLIENTE, y esta columna no es la llave primaria.
Para normalizar esta relacin, realizaremos los siguientes pasos:
1. Eliminaremos de la relacin rdenes, las columnas no llave (NOM_CLIENTE y
ESTADO) que tienen dependencia transitiva.
2. Creamos una nueva relacin con estas columnas, y adicionamos la columna no llave
ID_CLIENTE que caus la dependencia transitiva.
3. La nueva relacin Clientes tendr como clave primaria la columna que produjo la
dependencia transitiva, es decir, ID_CLIENTE.
ID_ORDEN

FECHA

ID_CLIENTE

2301

2/23/03

101

2302

2/25/03

107

2303

2/27/03

110

Tabla N 3.19 Tablas ORDENES en 3FN.

Fuente: El autor, 2009.
ID_CLIENTE

NOM_CLIENTE

ESTADO

101

MARTI

CA

107

HERMAN

WI

110

MARIA

MI

Tabla N 3.20 Tabla CLIENTES en 3FN.

Fuente: El autor, 2009.

3.7.6 Qu tan lejos debe llevar la normalizacin?

La siguiente decisin es qu tan lejos debe llevar la normalizacin? La normalizacin es
una ciencia subjetiva. Determinar las necesidades de simplificacin depende de nosotros. Si la
base de datos va a proveer informacin a un solo usuario para un propsito simple y existen
pocas posibilidades de expansin, normalizar los datos hasta la 3FN quiz sea algo
exagerado. Las reglas de normalizacin existen para crear relaciones que sean fciles de

25

manejar, as como flexibles y eficientes. A veces puede ocurrir que normalizar los datos hasta
el nivel ms alto no tenga sentido.
Se estn dividiendo relaciones slo para seguir las reglas o estas divisiones son en
verdad prcticas?. stas son el tipo de cosas que nosotros como diseadores de la base de
datos, necesitamos decidir, y la experiencia y el sentido comn nos pueden auxiliar para tomar
la decisin correcta. La normalizacin no es una ciencia exacta, ms bien subjetiva.
Existen seis niveles ms de normalizacin que no se han discutido aqu. Ellos son Forma
Normal Boyce-Codd, Cuarta Forma Normal (4NF), Quinta Forma Normal (5NF) o Forma
Normal de Proyeccin-Unin, Forma Normal de Proyeccin-Unin Fuerte, Forma Normal de
Proyeccin-Unin Extra Fuerte y Forma Normal de Clave de Dominio. Estas formas de
normalizacin pueden llevar las cosas ms all de lo que necesitamos. stas existen para
hacer una base de datos realmente relacional. Tienen que ver principalmente con
dependencias mltiples y claves relacionales.

3.7.7 Forma normal de Boyce-Codd

La Forma Normal de Boyce-Codd (FNBC) es una versin ligeramente ms fuerte de la
Tercera Forma Normal (3FN). La forma normal de Boyce-Codd requiere que no existan
dependencias funcionales no triviales de los atributos que no sean un conjunto de la clave
candidata. En una relacin en 3FN, todos los atributos dependen de una clave, de la clave
completa y de ninguna otra cosa excepto de la clave. Se dice que una relacin est en FNBC
si y solo si est en 3FN y cada dependencia funcional no trivial tiene una clave candidata
como determinante. En trminos menos formales, una relacin est en FNBC si est en 3FN y
los nicos determinantes son claves candidatas.
Solamente en casos raros una relacin en 3FN no satisface los requerimientos de la
BCNF. Un ejemplo de tal relacin es (teniendo en cuenta que cada estudiante puede tener
ms de un tutor), como el que se muestra en la tabla siguiente:
ID Tutor Nmero de seguro social del tutor ID Estudiante
1078

088-51-0074

31850

1078

088-51-0074

37921

1293

096-77-4146

46224

1480

072-21-2223

31850

Tabla N 3.21 Referencia cruzada de Tutor/Estudiante.

Fuente: El autor, 2009.

El propsito de la relacin es mostrar qu tutores estn asignados a qu estudiantes. Las

claves candidatas de la relacin son:
{ID Tutor, ID Estudiante}
{Nmero de seguro social del tutor, ID Estudiante}
Por lo tanto los tres atributos de la relacin son atributos primarios, es decir, los tres
atributos pertenecen a las claves candidatas. Recuerde que la 2FN prohbe dependencias
funcionales parciales de atributos no-primarios en las claves candidatas, y la 3FN prohbe

26

dependencias funcionales transitivas de atributos no-primarios en claves candidatas. Dado

que la relacin de arriba carece de cualquier atributo no-primario, est en 2FN y 3FN.
La FNBC es ms rigurosa que la 3FN en que no permite ninguna dependencia funcional
en la cual el conjunto determinante de atributos no sea una clave candidato (o superconjunto
de eso). La dependencia de ID Tutor en Nmero de seguro social del tutor es ese tipo de
dependencia. Por consiguiente, la relacin de arriba no est en FNBC.
Cualquier relacin que sea insuficiente en FNBC ser vulnerable a inconsistencias
lgicas. En la relacin de arriba poda ser representada una combinacin inconsistente de ID
Tutor y Nmero de seguro social del tutor.
En este caso, corregir el problema sera una simple cuestin de usar solo un esquema de
identificacin para los tutores: o el ID, o el nmero del seguro social, pero no ambos.

3.8 Ejercicios Propuestos.

1. Que condiciones deber cumplir una clave candidata, dentro de una entidad, para poder
ser la clave principal o llave primaria de la relacin correspondiente.
2. Objetivos del Diseo de Bases de Datos.
3. Existen relaciones ternarias en el modelo lgico relacional?
4. Obtenga los modelos lgicos a partir de los modelos conceptuales que se presentan a
continuacin, respectivamente:

A
Calle

Habitantes

Telfonos

Nombre

Estado
Ubicacin

Edificio
Direccin
Fuentes
Financieras

Avenida
Monto

RIF

Comunidad

Cdigo

Partida
Direccin

Numero
Aportes
Financieros

Proyecto
Urbanstico

A-P

Vivienda
Dueo
Elaborado

IDProyecto

Fecha

Nmero

NroCheque

Costo

rea

Descripcin

27

B
Nombre

Titulo

Apellido

Cedula

Docentes

D-P
Nombre
Telfono
FechaInicio

Cdigo

Cargo

D-P

IdDepartamento
Descripcin
Departamento

D-P

Proyecto

Costo

C
Rif
Salas

Cines

Nombre

Nombre
Direccin
Publica
IdCartelera

H. Salida

Actores

H. Inicio
Clase

FechaFinal

Carteleras

Funcin

Pelculas

Titulo
Responsable

C-P

Cdigo

FechaInicio

Papel

Gnero

28

5. En que consiste la normalizacin.

6. Mencione al menos 3 ventajas de una base de datos normalizada.
7. Cuando una relacin est en su 1FN?

29

8. Que es la dependencia funcional completa?

9. En que consiste la normalizacin
10. Cuando una relacin est en su 2FN?
11. Mencione al menos 2 ventajas de una base de datos normalizada hasta su 3FN.
12. Cuando una relacin est en su 3FN?
13. Que es dependencia transitiva?
14. Qu es eliminado en la relacin cuando se pasa de su 2FN a su 3FN?
15. Qu es eliminado en la relacin cuando se pasa de su 1FN a su 1FN?

30

16. Normalizar las siguientes relaciones a su 1FN, 2FN y 3FN. Colocar nombres a las relaciones resultantes y sealar el o los campos
claves.
#
Proyecto

Descripcin
Proyecto

Fecha
Inicio

#
Servicio

Descripcin

Cedula

Nombre
Analista

01

Pagina WEB

12-03-04

L-A

Diseo

258

Jos

01

Pagina WEB

12-03-04

L-A

Diseo

115

Omar

01

Pagina WEB

12-03-04

L-P

Programacin

357

Mara

22-05-02

L-A

Diseo

578

Jos

L-D

Administrador
BDD

02
02

BDD Control
Egresados
BDD Control
Egresados

22-05-02

258

Voz Sobre IP

18-11-03

L-T

Telefona

115

Omar

03

Voz Sobre IP

18-11-03

L-C

Diseo
Cableado

987

Mara

03

Voz Sobre IP

18-11-03

L-A

Diseo

258

Jos

04

Diseo
Multimedia

22-06-04

L-A

Diseo

525

Pablo

Horas
Asignadas

Lnea
Investig.

Descrip.
Investig.

#
Dpto.

Nombre
Departamento

Costo

Total
Asignado

L1

Software

01

Telemtica

1.002.581

3.000.000

Diseo
Navegacional
Diagrama de
Clases
Cdigos
Fuentes

L1

Software

01

Telemtica

1.002.581

3.000.000

L1

Software

01

Telemtica

1.758.685

3.000.000

L1

Software

02

Informtica

1.000.000

2.000.0000

11

L1

Software

02

Informtica

1200.000

2.000.000

Modelo Fsico
Construccin
BDD
Mascara de
RED
Tendido de
Cable
Protocolo de
Red
Diagrama de
Clase

Jos

03

Meta a
Alcanzar

L2

Redes

05

Electrnica

800.000

1.500.000

15

L2

Redes

05

Electrnica

900.000

1.500.000

22

L2

Redes

05

Electrnica

900.000

1.500.000

116

L3

Multimedia

02

Informtica

1.500.000

1.500.000

Etc..

N
Equipo

Pas
Equipo

Manager

N
Partido

Fecha
Partido

Lugar
Partido

Total
Goles
Partido

Cedula
Jugador

Nombre
Jugador

89
89
89
89
89
89
90
90
90
91
91
91
92
92
92

Brasil
Brasil
Brasil
Brasil
Brasil
Brasil
Vzla
Vzla
Vzla
Per
Per
Per
Chile
Chile
Chile

Juan
Juan
Juan
Juan
Juan
Juan
Luis
Luis
Luis
Pedro
Pedro
Pedro
Carlos
Carlos
Carlos

101
101
101
102
102
102
101
101
101
102
102
102
103
103
103

12-06-92
12-06-92
12-06-92
14-07-93
14-07-93
14-07-93
12-06-92
12-06-92
12-06-92
14-07-93
14-07-93
14-07-93
21-06-94
21-06-94
21-06-94

Caracas
Caracas
Caracas
Cuman
Cuman
Cuman
Caracas
Caracas
Caracas
Cuman
Cuman
Cuman
Guiria
Guiria
Guiria

5
5
5
7
7
7
5
5
5
7
7
7
3
3
3

11
22
33
11
22
33
87
88
89
91
92
93
67
68
69

Nelson
Joel
Pablo
Nelson
Joel
Pablo
Marcos
Paz
Veliz
Pez
Richard
John
Veltri
Can
Jeli

Cedula

Nombre

Telfono

Cdigo Cargo

Cargo

Cdigo Curso

Posicin
Jugador
Partido
Central
Arquero
Defensa
Lateral
Defensa
Arquero
Lateral
Arquero
Central
Lateral
Arquero
Defensa
Defensa
Arquero
Lateral

Goles
Anotados
Jugador

Resultado
Partido

Total
Partidos
Equipo

0
0
1
2
3
0
2
0
0
2
0
1
0
1
2

Ganador
Ganador
Ganador
Perdedor
Perdedor
Perdedor
Perdedor
Perdedor
Perdedor
Ganador
Ganador
Ganador
Perdedor
Perdedor
Perdedor

3
3
3
3
3
3
5
5
5
4
4
4
2
2
2

Nombre Curso

Nivel

Resultado

31

17
17
17
17
18
19
19
20
Etc.

Juana
Juana
Juana
Juana
Pedro
Pablo
Pablo
Mara

Nmero
Vendedor
3462
3462
3462
3593
3593
3593
Etc.

4512656
4512656
4512656
4512656
4312586
4161582
4161582
485748

Nombre de
Vendedor
Pedro
Pedro
Pedro
Juan
Juan
Juan

#Proyecto

Nombre

#Area

01
01
01
01
02
02
02
Etc..

Tejido seo
Tejido seo
Tejido seo
Tejido seo
El Espacio
El Espacio
El Espacio

01
01
02
02
03
03
01

01
01
01
01
01
02
02
02

rea de
Venta
Cumana
Cumana
Cumana
Carpano
Carpano
Carpano

Nombre
Area
Medicina
Medicina
Salud
Salud
Matemticas
Matemticas
Medicina

Analista-Diseador
Analista-Diseador
Analista-Diseador
Analista-Diseador
Analista-Diseador
Especialista en Redes
Especialista en Redes
Especialista en Redes

Nmero de
cliente
15-2
14-9
16-8
21-4
16-5
11-2

Cedula
investigador
11826857
15752863
11824757
534534
534534
15752863
8564145

1-AA
1-BB
1-JJ
1-CC
1-AA
1-CC
1-DD
1-FF

Nombre del
Cliente
Juana
Maria
Jos
Luis
Martha
Andres

Power Designer
PowerBuilder
Java
SQL Server
Power Designer
SQL Server
UNIX
Power Designer

Nmero de
Bodega
4
3
3
2
2
1

Avanzado
Bsico
Medio
Medio
Avanzado
Medio
Avanzado
Medio

Ubicacin de
Bodega
Pen
San Luis
San Luis
Monte Verde
Monte Verde
EL Silencio

Nombre

Depto.

Costo

Total Proyecto

Juan
Pedro
Ana
Luis
Luis
Pedro
Maria

Biologa
Alimentos
Biologa
Biologa
Biologa
Alimentos
Fsica

1000
1000
2000
2000
5000
5000
3000

3000
3000
3000
3000
8000
8000
8000

Fuente
Financiera
Ivic
Ivic
Ivic
Ivic
Cenamec
Cenamec
Cenamec

Aprobado
Reprobado
Aprobado
Reprobado
Rechazado
Aprobado
Rechazado
Aprobado

Importe de
venta
12586
12248
22568
58932
12562
42155

Tiempo
1 Ao
1 Ao
1 Ao
1 Ao
6 Meses
6 Meses
6 Meses

32

33