NORMALIZACIÓN.

Normalización es un conjunto de reglas que sirven para ayudar a los

diseñadores a desarrollar un esquema que minimice los problemas de lógica.
Cada regla está basada en la que le antecede. La normalización se adoptó
porque el viejo estilo de poner todos los datos en un solo lugar, como un
archivo o una tabla de la base de datos, era ineficiente y conducía a errores de
lógica cuando se trataba de manipular los datos. Por ejemplo, vea la base de
datos EMPRESA. Si almacena todos los datos en la tabla TRABAJO, ésta
podría verse como se muestra a continuación:

La normalización también hace las cosas fáciles de entender. Los seres

humanos tenemos la tendencia de simplificar las cosas al máximo. Lo hacemos
con casi todo desde los animales hasta con los automóviles. Vemos una
imagen de gran tamaño y la hacemos menos compleja agrupando cosas
similares juntas. Las guías que la normalización provee crean el marco de
referencia para simplificar la estructura. En su base de datos de muestra es
fácil detectar que usted tiene tres diferentes grupos: clientes, productos y
pedidos. Si sigue las guías de la normalización, podría crear las tablas
basándose en estos grupos.

El proceso de normalización tiene un nombre y una serie de reglas para cada

fase. Esto puede parecer un poco confuso al principio, pero poco a poco irá
entendiendo el proceso, así como las razones para hacerlo de esta manera. A
la mayoría de la gente le encantan las hojas de cálculo por la forma en la que
manejan sus datos. El tiempo que le lleve reconfigurar su esquema para
ajustarlo al proceso de normalización, siempre será bien invertido. Al fin y al
cabo, esto le tomará menos tiempo que el que tendría que invertir , para cortar
y pegar sus columnas de datos para generar el informe que quiere su jefe.

Otra ventaja de la normalización de su base de datos es el consumo de

espacio. Una base de datos normalizada puede ocupar menos espacio en
disco que una no normalizada. Hay menos repetición de datos, lo que tiene
como consecuencia un mucho menor uso de espacio en disco.

Dependencia funcional

B es funcionalmente dependiente de A.

Una dependencia funcional es una conexión entre uno o más atributos. Por
ejemplo si conocemos el valor de FechaDeNacimiento podemos conocer el
valor de Edad.
Las dependencias funcionales del sistema se escriben utilizando una flecha, de
la siguiente manera:

FechaDeNacimiento Edad

Aquí a FechaDeNacimiento se le conoce como un determinante. Se puede leer

de dos formas FechaDeNacimiento determina a Edad o Edad es
funcionalmente dependiente de FechaDeNacimiento. De la normalización
(lógica) a la implementación (física o real) puede ser sugerible tener éstas
dependencias funcionales para lograr la eficiencia en las tablas.

Dependencia funcional transitiva

Dependencia funcional transitiva.

Sean X, Y, Z tres atributos (o grupos de atributos) de la misma entidad. Si Y

depende funcionalmente de X y Z de Y, pero X no depende funcionalmente de
Y, se dice que Z depende transitivamente de X. Simbólicamente sería:

X Y Z entonces X Z

FechaDeNacimiento Edad

Edad Conducir

FechaDeNacimiento Edad Conducir

Entonces tenemos que FechaDeNacimiento determina a Edad y la Edad

determina a Conducir, indirectamente podemos saber a través de
FechaDeNacimiento a Conducir (En muchos países , una persona necesita ser
mayor de cierta edad para poder conducir un automóvil, por eso se utiliza este
ejemplo).
Formas Normales

Las formas normales son aplicadas a las tablas de una base de datos. Decir
que una base de datos está en la forma normal N es decir que todas sus tablas
están en la forma normal N.

En general, las primeras tres formas normales son suficientes para cubrir las
necesidades de la mayoría de las bases de datos. El creador de estas 3
primeras formas normales (o reglas) fue Edgar F. Codd.

Primera Forma Normal (1FN)

Una tabla está en Primera Forma Normal sólo si

• Todos los atributos son atómicos. Un atributo es atómico si los

elementos del dominio son indivisibles, mínimos.
• La tabla contiene una clave primaria.
• La tabla no contiene atributos nulos.
• Si no posee ciclos repetitivos.

Una columna no puede tener múltiples valores. Los datos son atómicos. (Si a
cada valor de X le pertenece un valor de Y, entonces a cada valor de Y le
pertenece un valor de X)

Esta forma normal elimina los valores repetidos dentro de una BD

Segunda Forma Normal (2FN)

Dependencia Funcional. Una relación está en 2FN si está en 1FN y si los

atributos que no forman parte de ninguna clave dependen de forma completa
de la clave principal. Es decir que no existen dependencias parciales.

En otras palabras podríamos decir que la segunda forma normal está basada
en el concepto de dependencia completamente funcional. Una dependencia
funcional es completamente funcional si al eliminar los atributos A de X
significa que la dependencia no es mantenida, esto es que A Є X, (X – {A}) -x->
Y. Una dependencia funcional es una dependencia parcial si hay
algunos atributos que pueden ser removidos de X y la dependencia
todavía se mantiene, esto es A Є X, (X – {A}) -> Y .

Por ejemplo {SSN, PNUMBER} HOURS es completamente dependiente

dado que ni SSN HOURS ni PNUMBER HOURS mantienen la
dependencia. Sin embargo {SSN, PNUMBER} ENAME es parcialmente
dependiente dado que SSN ENAME mantiene la dependencia

Tercera Forma Normal (3FN)

La tabla se encuentra en 3FN si es 2FN y cada atributo que no forma parte de

ninguna clave, depende directamente y no transitivamente, de la clave primaria.

Un ejemplo de este concepto sería que, una dependencia funcional X->Y en un

esquema de relación R es una dependencia transitiva si hay un conjunto de
atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene
X->Z y Z->Y.

Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva

en EMP_DEPT de la siguiente figura. Decimos que la dependencia de
DMGRSSN el atributo clave SSN es transitiva via DNUMBER porque las
dependencias SSN->DNUMBER y DNUMBER->DMGRSSN son mantenidas, y
DNUMBER no es un subconjunto de la clave de EMP_DEPT. Intuitivamente,
podemos ver que la dependencia de DMGRSSN sobre DNUMBER es
indeseable en EMP_DEPT dado que DNUMBER no es una clave de
EMP_DEPT.

DIAGRAMA DE ESTRUCTURA DE DATOS.

Un diagrama de estructura de datos es un esquema que representa el diseño

de una base de datos de red. Este modelo se basa en representaciones entre
registros por medio de ligas, existen relaciones en las que participan solo dos
entidades(binarias ) y relaciones en las que participan más de dos entidades
(generales) ya sea con o sin atributo descriptivo en la relación.
La forma de diagramado consta de dos componentes básicos:

Celdas: representan a los campos del registro.

Líneas: representan a los enlaces entre los registros.

Un diagrama de estructura de datos de red, especifica la estructura lógica

global de la base de datos; su representación gráfica se basa en el acomodo
de los campos de un registro en un conjunto de celdas que se ligan con otro(s)
registro(s), ejemplificaremos esto de la siguiente manera:

Consideremos la relación alumno-cursa-materia donde la relación cursa no

tiene atributos descriptivos :

Cuando el enlace no tiene atributos descriptivos

Caso 1. Cardinalidad Uno a Uno.

Caso 2. Cardinalidad Muchos a uno.

Caso 3. Cardinalidad Muchos a muchos.

MODELO ENTIDAD-ASOCIACIÓN.

El modelo E-R se basa en una percepción del mundo real, la cual esta formada
por objetos básicos llamados entidades y las relaciones entre estos objetos así
como las características de estos objetos llamados atributos.

Una entidad es un objeto que existe y se distingue de otros objetos de acuerdo

a sus características llamadas atributos . Las entidades pueden ser concretas
como una persona o abstractas como una fecha.

Un conjunto de entidades es un grupo de entidades del mismo tipo. Por

ejemplo el conjunto de entidades CUENTA, podría representar al conjunto de
cuentas de un banco X, o ALUMNO representa a un conjunto de entidades de
todos los alumnos que existen en una institución.