Está en la página 1de 9

C.B.T.I.

S 234

CATEDRATICO:
Cornelio Alberto Mndez Prez

ALUMNA:
Paola Alejandra Tecun Lio

ESPECIALIDAD:
Ofimtica

GRADO:
5 semestre

GRUPO:
A

TEMA:
Tres formas de diseo de una base de datos

FECHA:
23 de septiembre 2015

INTRODUCCION

En los siguientes temas de investigacin sobre las tres formas de diseo de una
base de datos nos dar conocer sobre la importancia y para que nos servir ms
adelante ya que ello nos ser de mucha ayuda si queremos hacer un diseo de
base de datos. A estas 3 reglas de Normalizacin se las conoce como las 3
FORMAS NORMALES.

TRES FORMAS DE DISEO DE UNA BASE DE DATOS


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. Si 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.
Un atributo es atmico si sus elementos se pueden considerar
Como unidades indivisibles:
Ejemplos de dominios no atmicos:
Nombre (atributo compuesto)
Telfonos (Atributos multivaluados)
Un esquema R satisface la primera forma normal si los
Dominios de todos los atributos son atmicos
Los valores no atmicos complican el almacenamiento y pueden
Provocar redundancia:
Por ejemplo, cuentas bancarias almacenadas con sus propietarios
7.4
Primera Forma Normal (Contd.)
Respetar la atomicidad y no intentis soluciones inteligentes

Por ejemplo una cadena de caracteres debe tener un significado


Indivisible.
Supongamos que en la base de datos de la universidad a los
Profesores se les asigna identificadores del tipo: LAN013
Donde los tres primeros caracteres se refieren al departamento en
El que se encuentran.
Hacer esto es una idea muy mala puesto que la informacin se
Codifica a nivel de programa y no de base de datos.
7.5

LA SEGUNDA FORMA NORMAL


(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.
Segunda Forma Normal
Cada atributo que no sea una clave primaria debe depender
nicamente de esa (de toda la clave primaria)
Para normalizar divide la tabla
Por ejemplo
Registro (estudiante id, estudiante -nombre, curso_ id,
curso_nombre)
Satisface el requerimiento de 1FN con clave primaria
(estudiante_id, curso id)
nombre_estudiante depende de estudiante_id pero no de la pareja
(estudiante_id, curso_id)

Divdase en tablas tres tablas


Estudiante (estudiante_id, estudiante_nombre)
Asignatura (curso_id, curso_nombre)
Registro (estudiante_id, asignatura_id)
Ahora podemos tener datos de estudiantes que no estn matriculados en
Ninguna asignatura, asignaturas que no tienen ningn estudiante y no
Necesitamos repetir los datos de estudiante/asignatura para cada registro
7.6
Segunda Forma Normal (cont)
ASEGURAROS DE NO PERDER INFORMACION AL PARTIR
LA RELACION EN VARIAS TABLAS
7.7

Veamos un ejemplo
VentaID ItemID FechaVenta ClienteVenta ProductoId Cantidad
1

01/12/2007 2

2334

10

01/12/2007 2

3333

01/12/2007 2

66643

34

01/12/2007 2

21

02/12/2007 5

3566

Ahi 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

2334

10

3333

66643

34

21

3566

Y ahora nuestra nueva tabla maestra


VentaId FechaVenta ClienteVenta
1

01/12/2007

02/12/2007

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 unico para cada grupo
de registros.

LA TERCERA 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 :
1. Ninguna Columna puede depender de una columna que no tenga una clave
2. No puede haber datos derivados

Definicin de dependencia transitiva: Un atributo depende


Transitivamente de la clave primaria si depende de otro atributo
Que a su vez depende de la clave
La tercera forma normal elimina estas dependencias
Por ejemplo
Pedido (pedido_id, fecha, cliente_id, cliente_nombre)
Satisface 1FN y 2FN con clave primaria pedido_id
Pero cliente_nombre cambia si cambia cliente_id
As que debemos dividir la tabla en:
Pedido (pedido_id, fecha, cliente_id)
Cliente (cliente_id, cliente_nombre)
Perteneciente a otra tabla, cualquier campo que sea subordinado de dicha clave
debe estar en otra tabla y no en nuestra tabla detalle.

CONCLUSION
Con estos temas de investigacin he llegado a la conclusin de que es muy
importante conocerlos ya que nos sern de mucha ayuda cuando realicemos un
diseo de base de datos y no equivocarnos con el procedimiento.

REFERENCIAS

ttps://cvva.wordpress.com/.../normalizacion-de-bases-de-datos-las-3-fo
phlonx.com/resources/nf3/nf3_tutorial_spanish.pdf