Sunteți pe pagina 1din 13

ESCUELA SUPERIOR POLITÉCNICA DE

CHIMBORAZO

SEMESTRE ABRIL 2018 – AGOSTO 2018

TAREA DE INVESTIGACION

IDENTIFICACION
Facultad: Informática y Electrónica

Carrera: Ingeniería En Electrónica, Control Y Redes Industriales

Materia: Base de Datos

Semestre: Cuarto

Docente: Ing. Blanca Hidalgo

Integrantes: William Colcha 904

Fecha: 04-06-2018

Calificación Revisado
INTRODUCCION

La normalización es el proceso mediante el cual se transforman datos complejos a un


conjunto de estructuras de datos más pequeñas, que además de ser simples y más estables
son fáciles de mantener.

Uno de los factores mas importantes en la creación de paginas web dinámica es el diseño
de las bases de datos(BD). Si las tablas no están correctamente diseñadas, puede causar
problemas a la hora de realizar complicadísimas llamadas SQL en el código PHP para
extraer los datos que necesite.

Para trabajar con MySQL o con Oracle, se debe tener conocimiento en métodos de
normalización del diseño de tablas en un sistema de base datos relaciona. Con este método
se puede obtener el código PHP más fácil de comprender, para la realización de la
aplicación.

La normalización esta encaminada en eliminar redundancia e inconsistencia de


dependencia en el diseño de las tablas.

Las llamadas formas normales van de la primera forma normal a la quinta, de forma que
una forma normal cumple las reglas de las formas normales que le preceden, si tenemos
una relación que cumple con la tercera forma normal esta debe cumplir con la segunda y
primera forma normal.
TEMA: Teoría de Normalización

Objetivo general

Transformar datos complejos a un conjunto de estructuras de datos más pequeñas, que


además de ser más simples y más estables, son más fáciles de entender.

Objetivos

Eliminar anomalías de actualización

Evitar la redundancia de datos

Evitar problemas de actualización de los datos en las tablas.

Que es la normalización

La normalización es el proceso mediante el cual se transforman datos complejos a un


conjunto de estructuras de datos más pequeñas, que además de ser más simples y más
estables, son más fáciles de manejar, además de tener reglas que ayuda a diseñar la base
de datos que desarrolle un esquema que minimice los problemas de lógica, cada regla esta
basada en la que la antecede.

La normalización se adopto por que 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 trataban de manipular los datos.

La normalización hace las cosas más fáciles de entender, el proceso de normalización


tiene un nombre y una serie de reglas para cada frase. Esto puede parecer un poco confuso
al principio, pero poco a poco se va entendiendo el proceso, así como las razones para
hacerlo de esta manera.

Grados de normalización

Existen básicamente tres niveles de normalización:

Primera forma normal (1NF)

Segunda forma normal (2NF)

Tercera forma normal (3NF)

Cada una de estas formas tiene sus propias reglas, cuando una base de datos se conforma
a un nivel, se considera normalizada a esta forma de normalización, no siempre es una
buena idea tener una base de datos conformada en el nivel más alto de normalización,
puede llevar a un nivel de complejidad que pudiera ser evitado si estuviera en un nivel
mas bajo de normalización.
REGLAS DESCRIPCION

Primera forma normal (1FN) Incluye la eliminación de todos los grupos


repetidos.

Segunda forma normal (1FN) Asegura que todas las columnas que no son
llave sean completamente dependientes de la
llave primaria (PK)

Tercera forma normal (1FN) Elimina cualquier dependencia transitiva.


Una dependencia transitiva es aquella en la
cual las columnas que no son llave son
dependientes de otras columnas que tampoco
son llave.

Tabla 1 Reglas

Normalización cero

usuarios

nombre Empresa Dirección_empresa url1 url2

Joe ABC 1work lane abc.com xyz.com

Jill XYZ 1 job street abc.com xyx.com

Tabla 1.1 normalización cero

Diríamos que a anterior tabla esta en normalización cero por que ninguna de las reglas de
normalización ha sido aplicada.

Primera forma normal (formalización/normalización)

Esta forma como ya lo había descrito en la tabla anterior es la que se va a encargar de


eliminar grupos repetitivos de las tablas individuales.

Crear una tabla separada por cada grupo de datos relacionados.

Identificara cada grupo de datos relacionados con una clave primaria.

Sea α un conjunto de atributo ∈ R, en donde R esta en la primera forma normal sin todos
los atributos α[n] son atómicos, es decir que no pueden seguir dividiéndose.
Ejemplo

userId Nombre Empresa Dirección_empresa url

1 Joe ABC 1work lane abc.com

1 Joe ABC 1work lane xyz.com

2 Jill XYZ 1job street abc.com

2 Joe XYZ 1job street xyz.com

Tabla 2 userId

Segunda forma normal (formalización/normalización)

Crear tablas separadas para aquellos grupos de datos que se aplican a varios registros.

Relacionar estas tablas mediante una clave externa.

Separando el campo url en otra tabla de forma que podemos añadir mas en el futuro sin
tener que duplicar los demás datos. También vamos a usar nuestra clave primaria para
relacionar estos campos.

Usuarios

UserId Nombre Empresa Direccion_empresa 1 1 abc.com


1 Joe ABC 1 work lane 2 1 xyz.com
2 Jill XYZ 1 job street 3 2 abc.com
Urls 4 2 xyz.com
UrIId relUserId url

Tabla 2.1 Usuarios Tabla 2.1.1 Usuarios

Se ha creado tablas separadas y la clave primaria en la tabla de usuarios, userId, esta


relacionada ahora con la clave externa en la tabla urls, relUserId. Pero que ocurre si
queremos añadir otro empleado a la empresa, para esto se aplicará el tercer nivel de F/N.
Tercera forma normal (formalización/normalización)

Esta es la que se encarga de eliminar aquellos campos que no dependan de la clave.

El nombre empresa y su dirección no tiene nada que ver con el campo userId, así que
tienen que tener su propio empresaId.

Usuarios

userId Nombre relEmpresaId

1 Joe 1

2 Jill 2

Empresas

emprId empresa Direccion_empresa

1 ABC 1 work lane

2 XYZ 1 job street

Urls

urlId RelUserId url

1 1 abc.com

2 1 xyz.com

3 2 abc.com

4 2 xyz.com

Tabla 2.2 (3FN)

Ahora la clave primaria emprId en la tabla empresas se relaciona con la clave externa
recEmpresaId en la tabla usuarios, y podemos añadir 200 usuarios mientras que solo
tenemos que insertar el nombre ABC una vez.
Forma normal de Boyce-Codd (FNBC)

Se define determinante en una relación a un atributo del cual depende funcionalmente de


manera completa cualquier otro atributo de la relación. Una relación esta en la forma
normal de Boyce-Codd sí, y solo si, todo determinante de ella es una clave candidata.

Teorema de Boyce-Codd: sea una relación R formada por los atributos A, B, C, D con
claves candidatas compuestas(A, B) y(B, C) tal que: A C, entonces la relación puede
descomponerse en cualquiera de las dos siguientes maneras: R1(A, C) y R1(B, C, D) o
bien, R1(A, C) y R2(A, B, D)

Ejemplo:

DNI NUM_SEG_SOC NOMBRE APELLIDO DEPARTA PUESTO SALARIO

413245-B 28-1234566 Juan Ramos Compras Gerente 2300


23456-J 28-2345686 Pedro Pérez Nominas Auxiliar 1200
123123-C 19-458766 María Gil Almacén Conserje 1530
1234556-B 45-223344 Antonio Sanz Compras Gestión 2200

Tabla 2.3 relación empleados

Respecto a los atributos de la relación vemos que NUM_SEG_SOC y el grupo


NOMBRE-APELLIDOS son claves candidatas(determinantes). Esta relación se
transforma en dos tablas: una contendrá la clave junto con las claves candidatas
(EMPLEADOS) y la otra con el resto de los campos (EMPLE-TRABAJO)

DNI NUM_SEG_SOC NOMBRE APELLIDOS

413245-B 28-1234566 Juan Compras

23456-J 28-2345686 Pedro Nominas

123123-C 19-458766 María Almacén

1234556-B 45-223344 Antonio Compras

Tabla 2.4 tabla relación empleados (FNBC)


DNI_(FK) DEPARTAMENTO PUESTO SALARIO

413245-B Compras Gerente 2300

23456-J Nominas Auxiliar 1200

123123-C Almacén Conserje 1530

1234556-B Compras Gestión 2200

Tabla 2.5 (FNBC)

Cuarta forma normal (formalización/normalización)

Una relación se encuentra en 4FN sí, y solo si, esta en FNBC y no existen dependencias
multivaluadas.

Es decir, si la relación es BCNF y las únicas dependencias multivalor permitidas son las
definidas sobre las claves candidatas, entonces se cumple.

FIGURAS COLOR TAMAÑO

ESFERA ROJO GRANDE

ESFERA VERDE GRANDE

CUBO BLANCO GRANDE

CUBO AZUL GRANDE

PIRAMIDE BLANCO MEDIANO

PIRAMIDE BLANCO GRANDE

PIRAMIDE ROJO GRANDE

Tabla 2.6 relación geométrica

De la tabla 2.6, FIGURA determina valores múltiples de COLOR y TAMAÑO pero


COLOR y TAMAÑO son independientes entre sí. Así pues, las dependencias son
FIGURA→→ COLOR y FIGURA→→TAMAÑO. Observamos que se repiten ESFERA-
GRANDE, o PIRAMIDE-BLANCO, o PIRAMIDE-GRANDE. Para eliminar la
redundancia de los datos se deben eliminar las dependencias de valores múltiples. Esto
se logras construyendo dos tablas, donde cada una almacena datos solamente uno de los
atributos de valores múltiples.
Ahora pasamos a 4FN en las siguientes tablas

FIGURA COLOR

ESFERA ROJO

ESFERA VERDE FIGURA TAMAÑO

CUBO BLANCO ESFERA GRANDE


CUBO AZUL
CUBO GRANDE
PIRAMIDE BLANCO
CUBO MEDIANO
PIRAMIDE BLANCO
PIRAMIDE GRANDE
PIRAMIDE ROJO

Tabla 2.7 COLOR en 4FN Tabla 2.8 TAMAÑOS en 4FN

Quinta forma normal (formalización/normalización)

Una relación se encuentra en 5FN sí, y solo si, toda dependencia de reunión en la relación
se una consecuencia de las claves candidatas. Esto es, la relación estará en 5FN si esta en
4FN y no existen restricciones impuestas por el creador de la base de datos. La 5FN se
refiere a dependencia que son extrañas.

Tiene que ver con tablas que pueden dividirse en subtablas, pero que no pueden
reconstruirse. Su valor practico ambiguo ya que conduce a una gran división de tablas

Nro. Nro. Nro.


Proveedor Producto Proyecto

S1 P1 J2

S1 P2 J1

S2 P1 J1

S1 P1 J1

Tabla 2.8 PROVEEDOR en 5FN


Nro. Nro.
Proveedor Producto

S1 P1

S1 P2

Tabla 2.8 no contiene la clave primaria Nro. Nro.


Producto Proyecto

P1 J1
Nro. Nro.
Proveedor Proyecto P1 J2

S1 J1 P2 J1

S1 J2 Tabla 2.10 no contiene la clave primaria

Tabla 2.9 no contiene la clave primaria

No está en 5(FN)

La solución seria

Nro. Nro.
Proveedor Producto

S1 P1

S1 P2
Tabla 2.11 no contiene la clave primaria Nro. Nro.
Producto Proyecto

P1 J1
Nro. Nro.
Proveedor Proyecto P1 J2

S1 J1 P2 J1

S1 J2 Tabla 2.12 no contiene la clave primaria

S2 J1

Tabla 2.13 no contiene la clave primaria

JOIN de las 3 proyecciones genera la relación original


Que tan lejos debe aplicarse la normalización

La normalización es una ciencia subjetiva. Determinar las necesidades de simplificación


depende de nosotros, si nuestra base de datos va a proveer información a un solo usuario
para un propósito simple y existen pocas posibilidades de expansión, normalizar los datos
has 3FN quizá sea algo exagerado.

Las reglas de normalización existen como guías para crear tablas que sean fáciles de
manejar, así como flexibles y eficientes. A veces puede ocurrir que normalizar los datos
hasta el nivel mas alto no tenga sentido.

Existen seis niveles de normalización, ellos son forma normal Boyce Codd, cuarta forma
normal (4NF), quinta forma normal(5NF) o forma normal de proyección unión, forma
normal de proyección-unión fuerte, forma normal de proyección-unión extrafuerte y
forma normal de clave de dominio, estas formas de normalización pueden llevar a cosas
mas allá de lo que necesitamos. Estas existen para hacer una base de datos realmente
relacional. Tiene que ver principalmente con dependencias múltiples y claves
relacionales.
CONCLUSIONES

La normalización es importante para obtener registros que permitan la adecuada


recuperación y transferencia de la información.

Además, con la normalización evitamos la redundancia de datos por el gran volumen de


información existentes.

Al aplicar normalización a los datos evitamos problemas en el momento de la


actualización de las tablas.

Bibliografía
carlos. (diciembre de 2017). platzi. Obtenido de https://platzi.com/blog/normalizar-una-base-
de-datos-y-no-morir-en-el-intento/

CVVA WEBLOG. (4 de diciembre de 2007). Obtenido de


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

Ed. (jueves de octubre de 2011). base de datos. Obtenido de


http://bdaranda.blogspot.com/2011/10/resumen-normalizacion.html

management, d. (20 de enero de 2017). KYOCERA . Obtenido de


https://smarterworkspaces.kyocera.es/blog/normalizacion-de-base-de-datos/

posted. (10 de may de 2016). power data. Obtenido de https://blog.powerdata.es/el-valor-de-


la-gestion-de-datos/por-que-se-necesita-la-normalizacion-de-base-de-datos

S-ar putea să vă placă și