CENTRO DE BACHILLERATO TECNOLGICO INDUSTRIAL Y DE SERVICIOS

CBTIS 243

NOBRE DEL ALUMNO: ARRIAGA MORALES PABLO FELIPE

ESPECIALIDAD: OFIMATICA

SEMESTRE Y GRUPO: 5 A

NOMBRE DE LA MATERIA: SUBMODULO

TEMA DEL TRABAJO:LAS TRES FORMAS NORMALES DE UN DISEO DE

UNA BASE DE BATOS

CATEDRTICO: CORNELIO ALBERTO MENDEZ PEREZ

FECHA DE ENTREGA: 23 DE SEPTIEMBRE DEL 2015

INTRODUCCION

Hoy aprenderemos la normalizacin de base de datos y las tres formas normales

de un diseo de base datos ya que esto nos ayudara a realizar nuestras tareas y

trabajo en clases y tambin para nuestra vida diaria ya que este tema es muy

importante.

NORMALIZACIN DE BASES DE DATOS

El proceso de normalizacin de bases de datos consiste en designar y aplicar una

serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relacin

al modelo relacional.

Las bases de datos relacionales se normalizan para:

Evitar la redundancia de los datos.

Disminuir problemas de actualizacin de los datos en las tablas.

Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relacin, aunque para que

una tabla sea considerada como una relacin tiene que cumplir con algunas

restricciones:

Cada tabla debe tener su nombre nico.

No puede haber dos filas iguales. No se permiten los duplicados.

Todos los datos en una columna deben ser del mismo tipo.

Relacin = tabla o archivo

Registro = registro, fila, rengln o tupla

Atributo = columna o campo

Clave = llave o cdigo de identificacin

Clave Candidata = superclave mnima

Clave Primaria = clave candidata elegida

Clave Ajena (o fornea) = clave externa o clave fornea

Clave Alternativa = clave secundaria

Dependencia Multivaluada = dependencia multivalor

RDBMS = Del ingls Relational Data Base Manager System que significa, Sistema

Gestor de Bases de Datos Relacionales.

1FN = Significa, Primera Forma Normal o 1NF del ingls First Normal Form.

Los trminos Relacin, Tupla y Atributo derivan del lgebra y clculo relacional,

que constituyen la fuente terica del modelo de base de datos relacional.

Todo atributo en una tabla tiene un dominio, el cual representa el conjunto de

valores que el mismo puede tomar. Una instancia de una tabla puede verse

entonces como un subconjunto del producto cartesiano entre los dominios de los

atributos. Sin embargo, suele haber algunas diferencias con la analoga

matemtica, ya que algunos RDBMS permiten filas duplicadas, entre otras cosas.

Finalmente, una tupla puede razonarse matemticamente como un elemento del

producto cartesiano entre los dominios.

Dependencia funcional:

Una dependencia funcional es una conexin entre uno o ms atributos. Por

ejemplo si se conoce el valor de DNI tiene una conexin con Apellido o Nombre.

Las dependencias funcionales del sistema se escriben utilizando una flecha, de la

siguiente manera:

Fecha De Nacimiento Edad

De la normalizacin (lgica) a la implementacin (fsica o real) puede ser sugerible

tener estas dependencias funcionales para lograr la eficiencia en las tablas.

B es funcionalmente dependiente de A.

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 entonces que Z depende transitivamente de X. Simblicamente sera:

X \right arrow Y \right arrow Z entonces X \right arrow Z

FechaDeNacimiento \rightarrow Edad

Edad \rightarrow Conducir

FechaDeNacimiento \rightarrow Edad \rightarrow Conducir

Entonces tenemos que FechaDeNacimiento determina a Edad y la Edad

determina a Conducir, indirectamente podemos saber a travs de

FechaDeNacimiento a Conducir (En muchos pases, una persona necesita ser

mayor de cierta edad para poder conducir un automvil, por eso se utiliza este

ejemplo).

"C ser un dato simple (dato no primario), B, ser un otro dato simple (dato no

primario), A, es la llave primaria (PK). Decimos que C depender de B y B

depender funcionalmente de A."

Dependencia funcional transitiva.

NORMALIZACIN DE BASES DE DATOS (LAS 3 FORMAS NORMALES)

Existen 3 niveles de Normalizacin que deben respetarse para poder decir que

nuestra Base de Datos, se encuentra NORMALIZADA, es decir, que cumple con

los requisitos naturales para funcionar ptimamente y no perjudicar las

Performance por mala arquitectura. Ests 3 reglas de Normalizacin se las conoce

como las 3 FORMAS NORMALES.

La Primera Forma Normal

Esta primera Forma Normal, nos lleva a no repetir datos en nuestras tablas. Los

famosos maestro detalle, deben aplicarse a la estructura de la tabla. S nuestra

tabla de ventas repite una y otra vez (por cada venta), el nombre, el domicilio y

otros datos del Cliente, es que no hemos aplicado esta Normalizacin.Si tenemos

una tabla clientes, en la tabla ventas, solo debera figurar el cdigo del cliente,

para que el resto de los datos se puedan referenciar automticamente sin

problemas y sin duplicar informacin. Lo mismo ocurrira en una tabla de detalle

de ventas, si por cada tem vendido colocamos el detalle del producto, con su

descripcin, medidas, etcTendramos un desaprovechamiento de espacio y

recursos muy grande. Para ello, tendremos nuestra tabla maestra de Productos y

con solo grabar el cdigo de dicho producto en nuestra tabla de ventas, ser

suficiente. Una tabla est en Primera Forma Normal si:

Todos los atributos son atmicos. Un atributo es atmico si los elementos del

dominio son simples e indivisibles.

La tabla contiene una clave primaria nica.

La clave primaria no contiene atributos nulos.

No debe existir variacin en el nmero de columnas.

Los Campos no clave deben identificarse por la clave (Dependencia Funcional)

Debe Existir una independencia del orden tanto de las filas como de las columnas,

es decir, si los datos cambian de orden no deben cambiar sus significados

Esta forma normal elimina los valores repetidos dentro de una Base de Datos.

La Segunda Forma Normal

l: Una relacin 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. (Todos los atributos que no son clave principal

deben depender nicamente de la clave principal).

En otras palabras podramos decir que la segunda forma normal est basada en el

concepto de dependencia completamente funcional. Una dependencia funcional x

\rightarrow y es completamente funcional si al eliminar los atributos A de X

significa que la dependencia no es mantenida, esto es que A \in X, X - \{A\}

\nrightarrow Y. Una dependencia funcional x \rightarrow y es una dependencia

parcial si hay algunos atributos A \in X que pueden ser eliminados de X y la

dependencia todava se mantiene, esto es A \in X, X - \{A\} \rightarrow Y.

Por ejemplo {DNI, ID_PROYECTO} \rightarrow HORAS_TRABAJO (con el DNI de

un empleado y el ID de un proyecto sabemos cuntas horas de trabajo por

semana trabaja un empleado en dicho proyecto) es completamente funcional dado

que ni DNI \rightarrow HORAS_TRABAJO ni ID_PROYECTO \rightarrow

HORAS_TRABAJO mantienen la dependencia. Sin embargo {DNI,

ID_PROYECTO} \rightarrow NOMBRE_EMPLEADO es parcialmente dependiente

dado que DNI \rightarrow NOMBRE_EMPLEADO mantiene la dependencia. (Si o

si debe estar previamente aplicada la Primera Forma Normal) La Segunda Forma

Normal nos habla de que cada columna de la tabla debe depender de la clave.

Esto significa que todo un registro debe depender nicamente de la clave

principal, si tuviramos alguna columna que se repite a lo largo de todos los

registros, dichos datos deberan atomizarse en una nueva tabla. Veamos un

ejemplo

Venta ID ItemID Fecha Venta Cliente Venta Producto Id Cantidad

1 1 01/12/2007 2 2334 10

1 2 01/12/2007 2 3333 2

1 3 01/12/2007 2 66643 34

1 4 01/12/2007 2 21 3

2 1 02/12/2007 5 3566 6

Ah tenemos un claro problema!!!Acaso no se busca NO REPETIR DATOS ?Si

toda una venta tendr el mismo nmero de Cliente y la misma FechaPor que no

crear una Tabla de MAESTRO DE VENTAS y que contenga esos 2 datos ?Es

evidente que la columna Cliente Venta y Fecha Venta se repetirn por cada venta

realizada. Es por ello que proponemos el siguiente esquema

Venta ID ItemID Producto Id Cantidad

1 1 2334 10

1 2 3333 2

1 3 66643 34

1 4 21 3

2 1 3566 6

Y ahora nuestra nueva tabla maestra

VentaId FechaVenta ClienteVenta

1 01/12/2007 2

2 02/12/2007 5

Entonces, nuestra 2da Forma Normal nos habla de que cada columna de una

tabla debe depender de toda la clave y no constituir un dato nico para cada grupo

de registros.

LA TERCERA FORMA NORMAL

La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia

funcional transitiva entre los atributos que no son clave.

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

esquema de relacin 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 va DNUMBER porque las dependencias

SSNDNUMBER y DNUMBERDMGRSSN 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.

Formalmente, un esquema de relacin R est en 3 Forma Normal Elmasri-

Navathe,2 si para toda dependencia funcional X \rightarrow A, se cumple al menos

una de las siguientes condiciones:

X es superllave o clave.

A es atributo primo de R; esto es, si es miembro de alguna clave en R.

Adems el esquema debe cumplir necesariamente, con las condiciones de

segunda forma normal. En realidad si nos guiamos en el ejemplo de esta nota, ya

no quedara normalizacin por aplicar y podramos decir que nuestro ejemplo

cumple con las 3 formas normales, ya que la 3ra Forma Normal nos habla de que:

Ninguna Columna puede depender de una columna que no tenga una clave

No puede haber datos derivados

En el 2do ejemplo hemos descubierto campos que dependan de la clave principal

(VentaID) y que podran incluirse en una tabla maestra. Pero supongamos un

ejemplo donde ciertas columnas no dependen de la clave principal y si dependen

de una columna de nuestra tabla.

VentaID ItemID ProductoID Cantidad Descripcin Medida Proveedor

1 1 3455 12 Impresora HP LJ8000

122cm 1

1 2 2455 34 Scanner HP A3555

33cm 1

2 1 5444 21 Mouse HP Wireless

1

Esto es muy normal encontrar en bases mal normalizadas. Vemos que los campos

DESCRIPCION, MEDIDA y PROVEEDOR no dependen de VENTAID y es por ello

que no deberan estar dentro de la tabla de detalle de ventas, ya que dependen de

PRODUCTOID.Aqui no se trata ya de eliminar grupos repetidos de datos (1ra

Forma Normal) sino que ante la inclusin de una clave perteneciente a otra tabla,

cualquier campo que sea subordinado de dicha clave debe estar en otra tabla y no

en nuestra tabla detalle.

CONCLUCION

Llegue de qu hoy aprend algo nuevo de las tres formas normales de un diseo

de una base de datos ya que esto nos ayudara en nuestra materia de submodulo y

utilizaremos nuestros conocimientos. Finalmente si tomamos en cuenta que una

tabla de detalle de venta (tem x tem) puede contener un volumen de millones de

registros, al haberle aplicado las 3 formas normales nos estaremos ahorrando

varios Gigabytes de tamao en dicha tabla y por supuesto mejorado notablemente

la performance.

REFERENCIAS

https://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos

https://cvva.wordpress.com/2007/12/04/normalizacion-de-bases-de-datos-las-3-

formas-normales/

http://biocomp.cnb.csic.es/~roberto/II/Docencia/SI1/Clase/Reserved/Formas_Norm

ales.pdf

https://support.office.com/es-hn/article/Conceptos-bsicos-del-diseo-de-una-

base-de-datos-eb2159cf-1e30-401a