1

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.

2

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

3

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.

4

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

Me llamas.

Celos de mi guitarra.

Jos Luis

Perales

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 Produccin

Jos Luis Perales Me llamas.

Jos Luis Perales Celos de mi

guitarra.

Jos Luis Perales Quisiera.

Es una relacin

5

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.

6

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 a

Julie Yessica a

7

Julie Jorge a

Csar Martn b

Csar Janet b

Csar Samantha b

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:

8

nmeros x y

1 a 1

2 a 1

3 a 1

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 a

Julie Yessica b

Julie Jorge c

Csar Martn d

Csar Janet e

Csar Samantha f

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.

9

apellido nombre departamento

Mendoza Martn 1

Mendoza Janet 2

Mendoza Jorge 3

Mendoza Kathy 4

Mendoza Carlos 5

Hidalgo Martn 2

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.

10

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 s

Janet 10 no

Carlos 14 s

Sabrina 16 s

Csar 18 s

Karen 20 s

11

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 S

Janet 10 S

Carlos 14 No

Sabrina 16 No

Csar 18 S

Karen 20 S

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:

12

TELEFONO

nombre anexo

Martn 10

Janet 10

Carlos 14

Sabrina 16

Csar 18

Karen 20

AUTORIZACIONES

anexo larga-distancia

10 S

14 No

16 No

18 S

20 S

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.

13

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.

14

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

15

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

16

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

17

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

18

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.

19

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.