Diseando una Base de Datos

Importancia de la Informacin
Actualmente los sistemas de informacin basados en computadoras ha cobrado la
mayor importancia dentro de las actividades cotidianas de una empresa. El
procesamiento de dicha informacin constituye el punto clave para la toma de
decisiones, es as cuando una empresa decide si es conveniente o no ingresar a un
nuevo mercado, o elaborar una estrategia frente a la competencia.
Aqu se resaltar la importancia del anlisis en el diseo de los archivos que compone
una Base de Datos, el cual es el punto de partida para el diseo de la Aplicacin, as
mismo se da las pautas necesarias para que usted amigo lector, sepa disear sus
informes, pantallas, as como la correccin y deteccin de errores en los datos de
entrada.

Definicin de Base de Datos

Es un conjunto de informacin, la cual ha sido organizada y presentada para servir a un
propsito especfico. Por Gestin de Base de Datos entenderemos a la organizacin
sistemtica de grandes lotes de informacin. Un buen ejemplo de Base de Datos es un
directorio telefnico, los datos se encuentran clasificados por orden alfabtico, por
departamentos, por profesin, etc. note que la informacin puede presentarse
organizada bajo diferentes formas, de modo que facilite la bsqueda, una extraccin o
la emisin de un listado.

Organizacin de los datos: el Modelo

Relacional
Una Base de Datos de tipo relacional se muestra como una o ms tablas rectangulares
basadas en filas o columnas. Cada una de estas tablas constituye un archivo de la
Base de Datos. Las filas son llamadas Registros y las columnas Campos. A cada
registro se le asigna automticamente un nmero secuencial es decir un nmero de
registro y a cada campo un nombre; el nombre del campo.
Una tabla presenta dos partes fundamentales: la Estructura de los registros y los datos.
La estructura es el armazn en el cual se almacena los registros, para definir una
estructura se debe sealar el nombre de cada columna (campo), el tipo (de acuerdo al
tipo de dato que se guarde) as como se debe reservar el espacio suficiente para que el
dato quepa (ancho de la columna).
Los registros de una tabla estn situados generalmente segn como hayan sido
ingresados, aunque es posible cambiar dicho orden y ordenarlo como mejor
precisemos: alfabtica, numrica o cronolgicamente

Diseo de la Base de Datos

En el diseo de una Base de Datos se busca evitar la redundancia de datos. Ya que
impone mayor dificultad para actualizar o para cambiar, por ejemplo cuando en un a
tabla de bases de datos se mantienen tanto los pedidos como las direcciones de los
clientes, si se cambia la direccin de un cliente significara cambiar en cada uno de los
pedidos hechos por este cliente en la tabla. Trasladar las direcciones de los clientes a
una tabla separada hace que sea ms fcil actualizar la direccin del suministrador,
slo se tendra que cambiar una direccin de un registro, en vez de cambiarla en cada
uno de los pedidos.
Cada una de las tablas en una base de datos debera contener solamente datos acerca
de una nica entidad. Por ejemplo, en una tabla de pedidos debera contener slo
columnas que contengan datos sobre pedidos. Una tabla de clientes debera contener
informacin slo de los clientes.
El proceso de asegurar la singularidad de los datos (as como el correspondiente
proceso de eliminar la redundancia de datos) se llama normalizacin.

1. Primera Forma Normal (1FN)

La primera forma normal establece que una tabla no puede contener grupos repetitivos.
Esto quiere decir que ningn grupo repetitivo de datos estar permitido en la tabla.
Cada uno de los registros debe tener el mismo nmero de atributos. Cada una las filas
debe tener el mismo nmero de columnas. Por ejemplo, veamos la siguiente tabla de
datos sobre cantantes que tienen varias producciones:

Intrprete

Produccin

Jos Luis

Me llamas.

Perales
Celos de mi guitarra.
Quisiera
No es una relacin

Cambiar una tabla con grupos repetitivos a una tabla sin ellos es simple. Se
reemplazan los grupos repetitivos por filas completas. Por ejemplo, pongamos la tabla
anterior en 1FN.

Intrprete
Jos Luis Perales
Jos Luis Perales

Produccin
Me llamas.
Celos de mi
guitarra.

Jos Luis Perales

Quisiera.
Es una relacin

Dependencia Funcional

La dependencia funcional muestra las asociaciones lgicas de los datos. La

dependencia funcional significa que los valores para dos columnas estn lgicamente
asociados. Para dos columnas A y B, el valor de B ser siempre el mismo para un valor
particular de A. El valor de A determina el valor de B. Si B es funcionalmente
dependiente de A, entonces A es el determinante de B.
Por ejemplo, considerar una organizacin donde cada uno de los individuos slo puede
trabajar para un nico jefe. Es importante para la estructura lgica del esquema que un
individuo est asociado nicamente con un jefe. El diseo lgico del esquema debe
mostrar de alguna forma que el jefe depende del empleado. Observe la siguiente tabla
con dos columnas, empleado y supervisor:
empleado

supervisor

Martn

Yessica

Janet

Yessica

Carlos

Yessica

Sergio

Julie

Hernn

Julie

Patricia

Julie

En este ejemplo, el valor de los datos en la columna llamada supervisor depende del
valor de los datos de la columna empleado. Seleccionar cualquier valor para empleado
nicamente determina un valor para supervisor. Por ejemplo si el valor para empleado
es Martn, entonces el valor de supervisor es siempre Yessica.
Empleado es el determinante de supervisor. Un simple diagrama de dependencias
muestra esta dependencia funcional.
i una persona puede trabajar para dos supervisores, esta dependencia funcional se
pierde. Por ejemplo, si Martn trabaja para Yessica y Julie.

empleado

supervisor

Martn

Yessica

Martn

Julie

Janet

Yessica

Carlos

Yessica

Sergio

Julie

Hernn

Julie

Patricia

Julie

Todava existe una relacin ya que existe una clave candidata. La clave candidata est
ahora compuesta de las dos columnas empleado-supervisor. Est todava en primera
forma normal, ya que no existen grupos repetitivos, ni las filas duplicadas. Sigue siendo
una tabla.
El supervisor no es una dependencia funcional sobre los empleados. Para un nico
valor de la columna empleado (Martn hay dos posibilidades valores de la columna
supervisor (Yessica y Julie ).
Ntese que la dependencia funcional es parte de la estructura de los datos, no es parte
del modelo relacional. Si Martn puede trabajar slo para un supervisor, los datos en
esta tabla estn mal, ya que es inconsistente con la estructura lgica de la empresa. La
tabla no sera un modelo exacto del mundo real. Nada en los datos la hace
inconsistente con el modelo relacional. Los datos, a pesar de todo, encajan en la tabla,
pero sta no modela el mundo real.

Dependencia Funcional y Columna Compuestas

Una columna puede ser funcionalmente dependiente de dos o ms columnas tomadas

juntas como una clave compuesta. Por ejemplo, observe la siguiente tabla:
Supervisor

Empleado

Departamento

Julie

Martn

Julie

Yessica

a
6

Julie

Jorge

Csar

Martn

Csar

Janet

Csar

Samantha

Aqu el departamento no es funcionalmente dependiente del nombre del supervisor, ya

que Martn est trabajando ahora para dos supervisores en dos departamentos
diferentes.
Poner dos columnas juntas, esto es, dos columnas compuestas, logra la dependencia
funcional. El departamento es funcionalmente dependiente de las columnas
compuestas empleado-supervisor.
El departamento es funcionalmente dependiente del supervisor y del empleado
tomados juntos. La estructura de los datos especifica que cualquier persona puede
trabajar para cualquier supervisor en un departamento dado. Esto es, el departamento
depende de los empleados y del supervisor.

Claves y Dependencia Funcional

Cada una de las otras columnas de una tabla depende funcionalmente de una clave
candidata.
Una clave candidata es un determinante para todas las columnas que no sean claves
candidata o primaria. La razn es que seleccionar una clave candidata individual
siempre selecciona los mismos valores para las columnas no clave.
Conviene notar que nada en la definicin de dependencia funcional dice que un
determinante sea clave candidata o primaria. Cualquier columna puede depender
funcionalmente de otra columna que no sea clave candidata. Observe el siguiente
ejemplo:

nmeros

En esta tabla, la columna x no es, obviamente, una clave candidata. Observe que y
depende funcionalmente de x, ya que debe tener el valor de 1 siempre que x tenga el
valor de a.
Dependencia Funcional Completa

Cualquier columna depende funcionalmente de forma completa de una columna

compuesta. Es funcionalmente dependiente de la columna compuesta pero no depende
funcionalmente de las columnas compuestas tomadas separadamente. Observe el
siguiente ejemplo:
supervisor

empleado

departamento

Julie

Martn

Julie

Yessica

Julie

Jorge

Csar

Martn

Csar

Janet

Csar

Samantha

En este ejemplo, la columna departamento depende funcionalmente de la columna

compuesta supervisor-empleado. En este conjunto de datos, cada uno de los
empleados trabaja en un nico departamento. Ya que el departamento tambin
depende funcionalmente de la columna empleado, entonces no tiene dependencia
funcional completa de las columnas compuestas supervisor-empleado.
8

apellido

nombre

departamento

Mendoza

Martn

Mendoza

Janet

Mendoza

Jorge

Mendoza

Kathy

Mendoza

Carlos

Hidalgo

Martn

Aqu la columna departamento depende funcionalmente de la columna compuesta

apellido-nombre. La columna departamento no depende funcionalmente slo de la
columna apellido o de la columna nombre. Ya que la columna departamento depende
funcionalmente de las columnas compuestas, es funcionalmente dependiente de forma
completa.
Las dependencias muestran la estructura de los dos datos en la base de datos. El
hecho de que el departamento dependa funcionalmente de forma completa de las
columnas compuestas apellido y nombre significa que cada uno de los individuos es de
un nico departamento (esto tambin significa que no hay dos personas en la
organizacin con el mismo nombre). Ya que es importante para la estructura de los
datos que un individuo est en un nico departamento, esta estructura debe ser
representada de alguna forma en el esquema de la base de datos. La estructura de los
datos en una base de datos puede ser especificada mediante el establecimiento de
dependencias funcionales.

Segunda Forma Normal: 2FN

Una tabla que est en 2FN debe estar, primero en 1FN y todas las columnas no clave
deben tener dependencia funcional completa de la clave primaria.
El ejemplo siguiente muestra una tabla usada anteriormente con dos columnas: nombre
y anexo.
nombre

anexo

Martn

10

Janet

10

Carlos

14

Sabrina

16

Csar

18

Karen

20

Esta tabla est en 1FN; no hay grupos repetitivos. Esta tabla est tambin en 2FN, ya
que la columna no clave anexo depende de la columna clave nombre.
El siguiente ejemplo aade otra columna a esta tabla que tambin depende de la clave
primaria (una columna de la hora a la que comienzan a trabajar los individuos). Esta
columna se llama hora. La columna hora indica si el individuo empieza a trabajar pronto
o tarde.
nombre

anexo

hora

Martn

10

Janet

10

no

Carlos

14

Sabrina

16

Csar

18

Karen

20

s
10

Esta nueva columna contiene informacin relacionada con la clave primaria. Un

individuo est autorizado para comenzar a trabajar pronto o tarde. Esto significa que
aadir la nueva columna a la tabla no ha cambiado el que est en 2FN.
Veamos ahora la tabla incluyendo la columna larga-distancia.

nombre

anexo

larga-distancia

Martn

10

Janet

10

Carlos

14

No

Sabrina

16

No

Csar

18

Karen

20

Esta tabla no est en 2FN, ya que la columna larga distancia no est relacionada con la
clave primaria nombre. La columna larga-distancia est relacionada con la anexo. La
columna larga-distancia no depende funcionalmente de forma completa de la columna
nombre.
La proyeccin de la tabla original en 1FN en dos tablas elimina cualquier dependencia
funcional no completa. Esta proyeccin cambia la tabla en 1FN en dos tablas 2FN. La
proyeccin crea dos tablas en 2FN, donde cada una de las dos tablas tiene una clave
primaria y columnas relacionadas con la clave primaria. Esto normaliza la tabla en 1FN.
Cada una de las nuevas tablas tiene dependencias funcionales ms simples. El
resultado apararece en las dos tablas siguientes:

11

TELEFONO
nombre

anexo

Martn

10

Janet

10

Carlos

14

Sabrina

16

Csar

18

Karen

20

AUTORIZACIONES

anexo

larga-distancia

10

14

No

16

No

18

20

El diagrama de dependencias funcionales predice el cambio de una tabla en 1FN en

dos tablas en 2FN.
Cada una de las dos dependencias se mueve a su propia tabla. La tabla de 1FN tiene
dos dependencias funcionales diferentes. Actuando sobre la tabla en 1FN, se crea una
nueva tabla para cada una de las dependencias.
Ntese que esta descomposicin se realiza sin prdida de informacin. Las dos tablas
que resultan pueden fcilmente recombinarse en una nica tabla.

12

Tercera Forma Normal: 3FN

En una tabla en 2FN, todas las columnas no clave deben tener dependencia funcional
completa con respecto a la clave primaria. Una tabla debe estar en 2FN antes de estar
en 3FN.
En una tabla en 3FN, todos los elementos no clave deben ser mutuamente
independientes. Las columnas no clave son todas mutuamente independientes si
ninguna de ellas es funcionalmente dependiente de otra. Para que una tabla est en
3FN, ninguna de las columnas no clave puede depender funcionalmente de cualquiera
de las otras columnas no clave.
Aqu hay una tabla con tres columnas, suministrador, estado y ciudad.
suministrador

regin

ciudad

s1

Norte

Trujillo

s2

Oriente

Iquitos

s3

Oriente

Iquitos

s4

Sur

Cusco

s5

Sur

Cusco

s6

Norte

Trujillo

En este conjunto de datos, cada uno de los suministradores corresponde a una ciudad
determinada. Cada una de las ciudades tiene una regin especfica. La regin depende
de la ciudad. La ciudad depende del suministrador.
Debido a que la ciudad depende del suministrador y la regin depende de la ciudad, la
regin tambin depende del suministrador. Si se conoce el suministrador, se puede
determinar la regin, pero slo a travs de la ciudad. La regin slo depende del
suministrador transitivamente a travs de la ciudad.
Esta clase de dependencia transitiva complica al actualizacin de la tabla. Si la regin
cambia para una ciudad, cada uno de los registros para esa ciudad deben ser
cambiados.

13

La insercin de un nuevo registro puede ser difcil. Aadir un registro para anotar que
una ciudad determinada pertenece a una regin en particular es imposible hasta que
haya un sumiminstrador para esa ciudad. Por ejemplo, no se puede aadir la
informacin de que Piura pertenece a la regin Norte hasta que haya un suministrador
para Piura.
Borrar la nica fila para una ciudad en particular hace perder dos elementos de
informacin: (1) la informacin de que un suministrador es de una determinada ciudad,
y (2) la informacin de que una ciudad pertenece a un regin.
Proyectar la tabla en 2FN en dos tablas separadas en 3FN resuelve este problema.
La proyeccin separa cada una de las dependencias funcionales en su propia tabla.
Las dos tablas que resultan son estas:

suministrador

ciudad

s1

Trujillo

s2

Iquitos

s3

Iquitos

s4

Cusco

s5

Cusco

s6

Trujillo

regin

ciudad

Norte

Trujillo

Oriente

Iquitos

Sur

Cusco

Cada una de estas dos tablas estn en 3FN. Cada una de las tablas est en 1FN ya
que no hay grupos repetitivos. Cada una de las tablas est en 2FN ya que las
columnas no clave son funcionalmente dependientes de la clave primaria. Cada una de
14

ellas est en 3FN ya que ninguna columna no clave es funcionalmente dependiente de

otra columna no clave. Est en tercera forma normal ya que una de las columnas es
mutuamente independiente.
En general, se pueden manipular las tablas ms fciles con dependencias simples.
Estas son ms fciles de actualizar. Este es el beneficio de las formas normales. Las
formas normales ayudan asegurar que las tablas, y un esquema, son simples
estructuralmente.
Eleccin de una descomposicin

Una tabla pueden descomponerse en componentes independientes, al conjunto de

tablas resultantes se llaman atmicas. Pueden decomponerse algunas tablas, pero no
hay por que hacerlas necesariamente.
A menudo hay ms de una posible descomposicin de una tabla. Examinemos al
siguiente tabla. En este ejemplo, los embarques son hechos desde un almacn y cada
uno de los almacenes tiene un estado de abierto o cerrado.
embarque

estado

almacn

s1

abierto

CA

s2

cerrado

NV

s3

abierto

CA

s4

cerrado

NV

s5

cerrado

NV

s6

cerrado

NV

La entrada del estado depende del almacn. Cada una de las entradas bajo almacn
tiene una entrada de estado de abierto o cerrado.
La entrada bajo almacn depende del embarque. Cada elemento de embarque navega
desde un nico lugar bajo almacn.
El estado depende del nmero de embarque. Cada uno de los embarques tiene un
estado asociado de abierto o cerrado. Ntese que esto probablemente no es parte de
la estructura lgica de los datos. Es razonable para el almacn que tenga un estado de
15

abierto o cerrado. No es razonable para un embarque que tenga un estado de abierto o

cerrado.
Dependencia Transitiva

Hay una interdependencia entre estado y almacn. El estado depende transitivamente

del nmero de embarque. El estado depende del nmero del embarque a travs de su
relacin con almacn. Esta proyeccin normaliza la tabla ejemplo en una tabla en 3FN.
almacn

estado

CA

abierto

NV

cerrado

embarque

almacn

s1

CA

s2

NV

s3

CA

s4

NV

s5

NV

s6

NV

Primer caso
Una proyeccin diferente tambin normaliza el ejemplo en dos tablas en 3FN. Esta segunda proyeccin
descompone la relacin en torno a la dependencia transitiva:

embarque

almacn

s1

CA

s2

NV

s3

CA

s4

NV

s5

NV

s6

NV

16

embarque

estado

s1

abierto

s2

cerrado

s3

abierto

s4

cerrado

s5

cerrado

s6

cerrado

Segundo caso
En el primer caso, cada una de las proyecciones es independiente. Actualizar una tabla no requiere
actualizar la otra (excepto donde cambie el almacn). El estado para un almacn puede cambiar,
independientemente del almacn para un embarque.

En el segundo caso, las proyecciones no son independientes. Cambiar el estado para

un almacn requiere actualizar ambas tablas.
En el primer caso, la unicidad de las claves persiste, pudindose reunir las dos tablas a
la vez, en una relacin en 2FN. Incluso despus de varias actualizaciones, se puede
unir dos tablas separadas en una tabla vlida en 2FN.
En el segundo ejemplo, una actualizacin a una relacin puede hacer imposible volver
a juntar las dos relaciones en una tabla en 2FN.
Borrando el primer registro de la tabla estado se hace imposible volver a combinar
todos los registros de ambas tablas en una nica tabla, no habra ningn registro para
un embarque en los resultados.

embarque

estado

almacn

s2

cerrado

NV

s3

abierto

CA

s4

cerrado

NV

s5

cerrado

NV

Fusin las tablas del segundo caso

17

Debido a que la dependencia funcional del estado sobre el almacn no ocurre dentro
de una nica tabla, existe una restriccin interrelacional entre las dos relaciones. Esto
hace que sea fcil ver que es preferible hacer una descomposicin donde las
proyecciones sean independientes a una donde no lo sean.
Las tablas son independientes solamente si las dependencias funcionales de la tabla
original pueden ser lgicamente deducidas de las dependencias funcionales de las
tablas compuestas. Tambin, los atributos que son comunes a las dos tablas deben ser
una clave candidata para al menos una de las tablas resultados.
Las tablas en la primera proyeccin son independientes. El atributo comn embarque
es la clave primaria para la tabla almacn. Todas las dependencias funcionales en la
tabla original aparecen en las proyecciones o pueden ser deducidas de ellas.
En el segundo ejemplo, las proyecciones no son independientes. La dependencia
funcional del estado sobre el almacn no puede ser deducida de las dependencias
funcionales en las tablas de resultado.

18

Conclusin
Se ha introducido los conceptos de dependencia funcional y normalizacin. La
dependencia funcional demuestra la estructura lgica de los datos en una base de
datos. Los diagramas de dependencia de datos pueden ayudar a determinar las
diversas dependencias de datos existentes en una tabla.
Las formas normales ofrecen guas para estructurar una base de datos con
dependencias de datos simples. En las diversas formas normales introducidas, cada
una de las formas est ms organizada que la anterior. Cada una de las formas
normales restringe un esquema que tiene menos complejidad de dependencia de datos
dentro de las tablas.

Eliminar los grupos repetitivos de datos puede reducir tablas que no estn en 1FN a
tablas que s lo estn.

Se puede proyectar un conjunto de tablas de 2FN procedentes de tablas en 1FN con

dependencias funcionales no completas sobre las columnas clave.

Se puede proyectar un conjunto de tablas en 3FN procedentes de tablas en 2FN que

tengan interdependencias entre las columnas no clave.

19