Construccin de bases de datos.

Tablas, campos y claves

DEFINICIN DE TABLAS
Las tablas constituyen la estructura principal de una base de datos. La creacin de tablas debe estar supeditada a la
representacin del dominio o el mbito de aplicacin de las mismas. Esto es en funcin de los procesos y actividades que
lleva a cabo una institucin, la informacin y documentacin que produce, su tratamiento y los servicios que ofrece. Las
tablas o entidades deben tener una denominacin que identifique el contenido de la informacin que almacenar, el
nombre del proceso que se desempea con la informacin almacenada o la finalidad en el tratamiento de la misma. Por
ejemplo el caso de una base de datos de un directorio de recursos web, plantea diversas cuestiones. En primer lugar, cmo
son los directorios web, qu informacin contienen, cmo se estructuran, cmo procesan la informacin, cmo la
representan y en definitiva cul es la cadena documental de la informacin hasta que finalmente es visualizada en forma
de directorio. En segundo lugar, la definicin de tablas viene dada en funcin de las caractersticas del caso y
procesamiento de la informacin del directorio, por ello una tabla de registro de recursos web es fundamental para
ingresar inicialmente los recursos. Pero los recursos deben ser descritos y catalogados, por lo tanto se necesita una tabla de
catlogo ms completa que la de registro. Adems los recursos web tienen caractersticas tipificadoras que los distinguen
como por ejemplo el tipo de recurso, la temtica que abordan, el pblico objetivo al que estn destinados. Ello implica una
tabla de tipos de recursos, una tabla de categoras temticas y una tabla de destinatarios.
Pero adems los recursos de un directorio web pueden ser valorados mediante comentarios o escalas. Esto significa que se
debern aadir una tabla que almacene los comentarios de los usuarios y una tabla que almacene las puntuaciones de los
mismos. Y si existen usuarios, tambin existirn administradores y trabajadores de la compaa o empresa responsable del
directorio que accedern al sistema con diferentes propsitos. Ello conlleva una tabla de usuarios y una tabla de
administradores. Pero adems dentro de los usuarios y administradores existen distintas categoras, por lo tanto tenemos
usuarios ms o menos experimentados y administradores con distintos rangos de acceso a las funciones y posibilidades del
sistema de informacin del directorio web

DEFINICIN DE CAMPOS
Los campos de una tabla de una base de datos son fundamentales para guardar la informacin de una manera
completamente estructurada y ordenada. Esto es definir los rasgos, caractersticas y aspectos que deben ser tenidos en
cuenta para describir o procesar cada uno de los tems, objetos, elementos sujetos a descripcin. Por ejemplo, una tabla de
comentarios de un directorio web, tendr que contener una informacin tal que permita obtener el usuario que hizo el
comentario, el recurso sobre el cul se realiz el comentario, el comentario propiamente dicho, la fecha en la que se
realiz el comentario, si el comentario forma parte de una respuesta a otro comentario. Todo ello puede ser definido en los
campos id (de identificacin), id_usuario (campo clave externo para identificar el usuario), id_recurso (campo clave
externo para identificar el recurso web), texto (campo que almacena el texto del comentario), fecha1 (campo para la fecha
del comentario), fecha2 (campo para la fecha de la edicin del comentario), id_comentario (campo clave externo para
identificar el comentario que suscita la rplica del presente comentario). A parte de identificar los campos necesarios es
necesario definir la tipologa de los campos o lo que es lo mismo, el tipo de informacin que stos contendrn
DEFINICIN DE CLAVES
Los campos claves, tal como se explic en el apartado anterior, permiten identificar de manera unvoca cada objeto,
elemento o registro de una tabla o entidad. Por este motivo se debe tener en cuenta que su control interno a efectos del
sistema de informacin propiamente dicho, deba ser lo ms sencillo posible. Con este objetivo, los campos claves
principales primarios, suelen ser campos de tipo numrico, con propiedad autonumrica correlativa basada en un
incremento unitario, es decir de tipo +1. Para facilitar la tarea de diseo de campos y tablas, se aconseja que el campo
clave principal sea denominado siempre como campo "id" en minsculas. Para definir los campos externos o forneos
destinados al almacenamiento de un nmero identificador de una tabla externa para realizar algn tipo de relacin, se
aconseja que el tipo de campo sea numrico entero de tamao medio y con una nomenclatura similar a la siguiente
"id_nombretabla" en donde "id" representa que se trata de un campo clave de identificacin, "_" que el campo relaciona
una tabla externa y "nombretabla" es el texto que habr que sustituir por el nombre de la tabla en minsculas y con todo el
nombre seguido sin espacios.
Atributos y Dominios

1.Atributos
1.1 Definicin
En bases de datos, un atributo representa una propiedad de inters de una entidad.
Los atributos se describen en la estructura de la base de datos empleando un modelo de datos.
Por ejemplo, se podra tener una entidad llamada "Alumno". Esta entidad puede estar constituida por uno o ms atributos,
que son propiedades de la entidad "Alumno" que interesan para almacenarse en la base de datos. Por ejemplo, la entidad
"Alumno" podra tener los atributos: nombre, apellido, ao de nacimiento, etc.
La eleccin de los atributos de una entidad depende del uso que se le dar a la base de datos. El alumno puede tener una
"religin", pero si no interesa al fin de la base de datos, no es necesario almacenarla en un atributo.
En SQL un atributo es llamado columna.
1.2 Caractersticas
Cada atributo de una relacin se caracteriza por un nombre y por un dominio. El dominio indica qu valores pueden ser
asumidos por una columna de la relacin. A menudo un dominio se define a travs de la declaracin de un tipo para el
atributo (por ejemplo diciendo que es una cadena de diez caracteres), pero tambin es posible definir dominios ms
complejos y precisos. Por ejemplo, para el atributo "sexo" de nuestra relacion "Personas" podemos definir un dominio por
el cual los nicos valores vlidos son 'M' y 'F'; o bien por el atributo "fecha_nacimiento" podremos definir un dominio por
el que se consideren vlidas slo las fechas de nacimiento despus del uno de enero de 1960, si en nuestra base de datos
no est previsto que haya personas con fecha de nacimiento anterior a esa.

2.Dominios
2.1 Definicin
Un dominio describe un conjunto de posibles valores para cierto atributo. Como un dominio restringe los valores del
atributo, puede ser considerado como una restriccin. Matemticamente, atribuir un dominio a un atributo significa "todos
los valores de este atributo deben de ser elementos del conjunto especificado".
Distintos tipos de dominios son: enteros, cadenas de texto, fecha,no procedurales etc.
2.2 Caractersticas
Caracterstica fundamental de los dominios de una base de datos relacional es que sean "atmicos", es decir que los
valores contenidos en las columnas no se puedan separar en valores de dominios ms simples. Ms formalmente se dice
que no es posible tener atributos multivalor (multivalued). Por ejemplo, si una caracterstica de las personas en nuestra
base de datos fuese la de tener uno o ms hijos, no sera posible escribir la relacin Personas de la siguiente manera:
Personas (nombre, apellido, fecha_nacimiento, sexo, estado_civil, hijos)

Modelo Entidad-Relacin
Este modelo es solo y exclusivamente un mtodo del que disponemos para disear esquemas que posteriormente
debemos de implementar en un gestor de BBDD (bases de datos). Este modelo se representa a travs de diagramas y
est formado por varios elementos.

Este modelo habitualmente, adems de disponer de un diagrama que ayuda a entender los datos y como se relacionan
entre ellos, debe de ser completado con un pequeo resumen con la lista de los atributos y las relaciones de cada elemento.

Elementos del modelo entidad-relacin

Entidad

Las entidades representan cosas u objetos (ya sean reales o abstractos), que se diferencian claramente entre s.

Para poder seguir un ejemplo durante el artculo aadir ejemplos sobre un taller mecnico, donde se podra crear las
siguientes entidades:

Coches (objeto fsico): contiene la informacin de cada taller.

Empleado (objeto fsico): informacin de los trabajadores.
Cargo del empleado (cosa abstracta): informacin de la funcin del empleado.

Estas entidades se representan en un diagrama con un rectngulos

Atributos

Los atributos definen o identifican las caractersticas de entidad (es el contenido de esta entidad). Cada entidad contiene
distintos atributos, que dan informacin sobre esta entidad. Estos atributos pueden ser de distintos tipos (numricos, texto,
fecha...).

Siguiendo el ejemplo de antes podemos analizar los atributos de nuestra entidad "Coches", que nos darn informacin
sobre los coches de nuestro supuesto taller.

Unos posibles atributos seran los siguientes: nmero de chasis, matrcula, DNI del propietario, marca, modelo y muchos
otros que complementen la informacin de cada coche.

Los atributos se representan como crculos que descienden de una entidad, y no es necesario representarlos todos, sino los
ms significativos

En un modelo relacional (ya implementado en una base de datos) una ejemplo de tabla dentro de una BBDD podra ser el
siguiente.

Nmero de chasis Matrcula DNI del propietario

5tfem5f10ax007210 4817 BFK 45338600L
6hsen2j98as001982 8810 CLM 02405068K
5rgsb7a19js001982 0019 GGL 40588860J

Este ejemplo es con tres atributos, pero un coche podra tener cientos (si fuese necesario) y seguiran la misma estructura
de columnas, tras implementarlo en una BBDD.

Relacin

Es un vnculo que nos permite definir una dependencia entre varias entidades, es decir, nos permite exigir que varias
entidades compartan ciertos atributos de forma indispensable.

Por ejemplo, los empleados del taller (de la entidad "Empleados") tienen un cargo (segn la entidad "Cargo del
empleado"). Es decir, un atributo de la entidad "Empleados" especificar que cargo tiene en el taller, y tiene que ser
idntico al que ya existe en la entidad "Cargo del empleado".

Las relaciones se muestran en los diagramas como rombos, que se unen a las entidades mediante lneas.
3. Normalizacion

Qu es normalizacin?

Normalizacin es un proceso que clasifica relaciones, objetos, formas de relacin y dems elementos en grupos, en base a
las caractersticas que cada uno posee. Si se identifican ciertas reglas, se aplica un categora; si se definen otras reglas, se
aplicar otra categora.

Estamos interesados en particular en la clasificacin de las relaciones BDR. La forma de efectuar esto es a travs de los
tipos de dependencias que podemos determinar dentro de la relacin. Cuando las reglas de clasificacin sean ms y ms
restrictivas, diremos que la relacin est en una forma normal ms elevada. La relacin que est en la forma normal ms
elevada posible es que mejor se adapta a nuestras necesidades debido a que optimiza las condiciones que son de
importancia para nosotros:

La cantidad de espacio requerido para almacenar los datos es la menor posible;

La facilidad para actualizar la relacin es la mayor posible;

La explicacin de la base de datos es la ms sencilla posible.

Primera forma normal

Para que una relacin est en primera forma normal (1 FN), debe ser solamente una
relacin propia, una matrz m por n, donde:

Ninguna celda de la matriz est vaca;

El valor n cualquier columna est definido por el dominio para dicho atributo.

Cada tupla tiene una clave que la identifica en forma unvoca, pero dicha clave no
significa orden.

La aplicacin determina la relacin

Para que una relacin sea normalizada en pasos adicionales, debe encontrarse en la
primera forma normal. Colocar los datos en la primera forma normal est a cargo del
diseador de la aplicacin. Estos datos se encuentran disponibles de alguna manera
inicialmente. Si la aplicacin existe en forma manual, o ha sido anteriormente
computarizada pero no todava como relacin, el diseador reorganiza los datos de
modo de conformar una matrz 1FN.

La segunda inicial ms importante es la dimensin de la relacin cuntos

componentes existen en la tupla o cuntas columnas en la tabla? De qu manera se
compara esto con el nmero de campos en el documento fuente?.

En la figura se puede observar un documento como muestra, una factura tpica. Parte
de la informacin es fija y otra variable. La figura nos muestra un formulario impreso
dentro de l cual se ha agregado informacin. La impresin puede dividirse en dos
categoras.
 Informacin descriptiva para el usuario

Nombres de atributos.

La informacin impresa es necesariamente fija. Podemos observar el nombre de la

compaa en la figura, as como otras particularidades (tales como el nmero de
telfono que no figura aqu). Otros nombres impresos corresponden a los atributos
cuyos valores se escriben en el momento en que el formulario es llenado. Estos
nombres de atributos son tambin los nombres de campos para almacenar los datos
en el sistema. Los que se escribe son los valores de atributos.

La informacin convertida queda formada en tuplas. La prxima pregunta es cuantas

tuplas representarn a la formacin en esta forma. Debe notarse que el nmero de
partes ordenadas vara de una factura o pedido a otro.

Segunda Forma Normal

Una relacin est en segunda forma normal (2FN) solamente si todos los atributos son
dependientes en forma completa de la clave.

Descripcion De La Segunda Forma Normal (2 Fn)

Su nombre ya nos indica el hecho de que la segunda forma normal es por lo general el
prximo paso de normalizacin y descomposicin. Para ser accesible a la normalizacin, y
poder ser puesta en segunda forma normal, la relacin debe poseer las siguientes
propiedades:

Debe estar en primera forma normal

Debe tener una clave compuesta.

La consecuencia inmediata de los requerimientos expresados ms arriba es que cualquier

relacin en primera forma normal que tiene una clave simple, est automticamente en
segunda forma normal. Comencemos con un ejemplo en forma de tabla de una relacin
consistente en 17 atributos, que se presenta en la figura. La misma se encuentra en primera
forma normal y tiene una clave compuesta que consiste en dos atributos P y Q.

Estos estn subrayados en la figura para mostrar que sirven como clave. La tupla de
relacin puede tambin escribirse linealmente en forma simblicamente:

R = (A,B,C,D,E,F,G,H,I,L,M,N,O,P,Q)

El prximo paso es crear un grafo de dependencia, presentando aqu como figura. Debe
notarse que este grafo se crea examinado con conocimientos y atributos para determinar
como participan y relacionan entre ellos.
No resulta suficiente analizar la matrz de relacin, la cual puede hacernos creer que existe
una dependencia debido a que la muestra de la cual se ha extrado dicha relacin es
pequea. Si somos inducidos a error por los datos existentes y construimos una
dependencia donde esta no existe, se plantear un problema. Cuando lleguen nuevos datos
que contradigan la dependencia, deber dejarse de lado el esquema completo.

Supongamos en consecuencia que el grafo que se puede observar en la figura ha sido

derivado en forma funcional y que expresa correctamente las dependencias. Resulta claro a
partir de este grafo que los atributos que parten de P son dependientes solamente de este.
De un modo similar los que parten de Q dependen solamente de este ltimo. Solamente
aquellos que parten de la lnea de trazos que conecta a P y Q tienen dependencia completa
de ambos. Esta es la gua para la descomposicin.

Tercera forma normal

Una relacin se encuentra en tercera forma normal (EFN) si no existen transitividades entre
sus atributos y si ya se encuentra en 2 FN.

Descripcin

Una relacin R a poner en tercera forma normal debe estar en la segunda forma normal. Es
muy comn que R sea una sub-relacin; la relacin original estaba en primera forma
normal (para ponerla en segunda forma normal fue descompuesta en varias sub-relaciones).
Estas son ahora candidatas a una descomposicin adicional.

Recordamos que las propiedades de la segunda forma normal (2Fn) son:

Tenemos una matrz m x n con un valor determinado para cada componente de cada tupla.

Cada valor es obtenido a partir de un dominio propiamente definimos

Cada valor contiene una clave, ya sea simple o compuesta

Cada componente no clave es dependiente en forma completa de su clave.

En consecuencia es evidente que tenemos, o bien una clave simple, o una clave compuesta
de la cual todos los componentes no clave son dependientes en forma completa.

El objeto de esta fase es determinar todas las dependencias transitivas; la descomposicin

producir a continuacin sub-relaciones para las cuales no existirn dependencias
transitivas -la definicin de la tercera forma normal (EFN)-.

Una dependencia transitiva abarca como mnimo tres componentes. Si los componentes
fueran ms, la dependencia mltiple puede derivarse en varias dependencias atransitivas de
tres componentes solamente dada una. Por lo tanto dirigiremos nuestra atencin a una
dependencia transitiva simple de tres componentes. Tal dependencia puede expresarse
como:

Q ---> A ----> B

En la cual se dice que B depende de A y que A depende de Q. La transitividad existe

debido a que el valor de B depende en la ltima instancia del valor de Q.

La dependencia transitiva es degenerada si cualquiera de las dependencias anteriores es

total. Esto es, podemos prever que la relacin de Q a A es muchos-unos, donde varios valor
nico de A. Dado un valor tal Q el valor de A queda determinado. La inversa no se aplica y
en consecuencia no existe una dependencia total: dado un valor de A el valor
correspondiente de Q no queda determinado a menos de que se trate de una dependencia
total.

Cuarta forma normal

Dependencias multivaluadas

La tercera forma normal toma en cuenta la dependencia transitiva y provee una reduccin
ptima universal, excepto para los casos infrecuentes de dependencia multivaluadas. Ha
quedado claro en pocas recientes que es posible una reduccin adicional en este caso, y
esto es lo que se lleva a cabo mediante la cuarta forma normal.

Existe una dependencia multivaluada cuando un valor de una variable est siempre
asociado con varios valores de otra u otras variables dependientes que son siempre las
mismas y estn siempre presentes. Esto se ilustra mejor con el ejemplo presentado en la
figura. La relacin FAB describe tejidos. La variable independiente (con respecto a las
dependencias (multivaluadas) es el nmero de tejido FABNO. Con el se encuentra
asociados un modelo (o patrn) y un color. En la figura, el tejido 345 vienen en dos
modelos y entres combinaciones de modelo y color. En este caso se aplica el grafo de
dependencia. Para hacer mas clara que esta es una dependencia multivariable, una cabeza
doble de flecha apunta desde FABNO o PATRN y tambin desde FABNO a COLOR.

La ineficiencia en el registro de informacin y se resulta clara al examinar las dos nuevas

relaciones. La primera de stas, FABPAT lista el nmero de tejido contra el modelo; en el
segundo caso, FABCOL, lista el nmero de tejido contra las combinaciones de color. Dado
que la regla es que todas las combinaciones de las variables dependientes multivaluadas
deben prevalecer, resulta simple reconstruir la relacin FAB a partir de las dos sub-
relaciones que resultaron.