Dirección General de Educación Superior Tecnológica

Instituto Tecnológico Superior de Champotón

Carrera:
Ingeniería en logística
Docente: José Eduardo Euan González
Materia: Base de datos

Tema: Normalización (1FN, 2FN, 3FN y FNBC.)

Alumnos (as):

Matrícula Nombre (s)

201080090 Dalila Moreno Posadas

Champotón, Campeche, a 23 de junio del 2022

Introducción:

Las formas normales son conjuntos de criterios que utilizamos para «normalizar»
(es decir, mejorar la estructura) de las bases de datos.

En la presente investigación realice una investigación de los temas de la

normalización.

Formas Normales (1FN, 2FN, 3FN y FNBC)

Una tabla está en Primera Forma Normal si:

• Todas las propiedades son "descendencia". Por ejemplo, en el área de

telefonía, no tenemos muchos teléfonos.
• La tabla contiene una clave primaria única. Por ejemplo, un número de
identificación fiscal (TIN) para una persona, una placa o un identificador
autoincrementar simple. Si no tienes la clave, no es 1FN.
• La clave principal no tiene un atributo vacío. No podemos tener líneas sin
llaves (por ejemplo, personas sin TIN o autos sin placas).

• No debe haber ningún cambio en el número de columnas. Si algunas filas

tienen 8 columnas y otras 3, entonces no estamos en 1FN.
• Los campos no clave deben especificarse con una clave. En otras
palabras, los campos que no son clave dependen funcionalmente de la
clave. Es bastante similar a decir que hay una clave principal.
• Debe haber independencia en el orden de las filas y columnas, es decir, si
los datos cambian de orden, su significado no debe cambiar. Por ejemplo, si
en la columna 1 tenemos el primer apellido y en la columna 2 tenemos
el segundo nombre, entonces no estamos en 1FN. Del mismo modo, si en la
tercera línea tenemos el tercero mejor y en la quinta línea tenemos
un quinto, entonces no estamos en 1FN.

2FN – Segunda Forma Normal

Una tabla está en 2FN si, además de estar en 1FN, comprueba que los atributos no
clave dependen de todas las claves primarias.

Por ejemplo, si tenemos una tabla con personas, identificadas por su NIF y
recogemos la dirección de la empresa y trabajo, entonces la clave será NIF-
Empresa. Pero nos encontraremos con que una misma persona puede trabajar en
varias empresas. Y vemos que la dirección de la empresa no
depende totalmente de la clave primaria, solo de la empresa. Así que no estamos
en 2FN.

3FN – Tercera Forma Normal

La tabla es 3NF si no hay dependencias transitivas entre atributos no clave además

de ser 2FN.

Como dijo Bill Kent: “Cualquier atributo que no sea clave debe proporcionar
información sobre la clave, toda la clave y solo la clave... con la ayuda de Codd”.

Supongamos que tenemos una tabla de ganadores de un torneo de

tenis. Contiene el nombre del torneo, año, nombre del ganador y nacionalidad. La
clave será Torneo-Año. Bueno, esta tabla no está en 3NF porque el
atributo de nacionalidad, que no se toma de la palabra clave, depende del nombre
del ganador (también depende de la
clave). Supongamos que la nacionalidad informa del ganador, pero no de la
clave. Esta es una dependencia transitiva porque la nacionalidad
depende del ganador que a su vez depende del año del torneo.

FN de Boyce-Codd

Es FN un poco más estricto que 3NF. Más precisamente, debe estar en 3NF y
no contener dependencias funcionales sin importancia para atributos que no son un
conjunto de claves candidatas. En otras palabras: la tabla está en BCNF si está
en 3NF y los únicos selectores (atributos que dependen de otros atributos) son
claves candidatas.

Es muy difícil si la tabla en 3FN no está en BCNF, pero podemos "llegar

allí" eligiendo la clave incorrecta para nuestra tabla. Por ejemplo, si tenemos una
tabla con idWorker, idDepartment e id Responsable donde id Responsable es el
operador. Es importante que cada empleado trabaje en varios departamentos
y tenga diferentes responsables (idWorker, idDepartment, id Responsable). Pero si
resulta que cada gerente pertenece a un departamento individual, entonces id
Responsable dependerá del idDepartment, haciendo que id Responsable esté
"seleccionado" (una propiedad depende de otra), pero no es la clave candidata.

Este problema se resolverá creando otra tabla (idDepartment, id responsable) y

eliminando id responsable de la entidad anterior.

Conclusión:

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

adecuada recuperación y transferencia de la información.

La normalización de bases de datos toma un esquema relacional y le aplica un

conjunto de técnicas para producir un nuevo esquema que representa la misma
información, pero contiene menos redundancia y evita posibles anomalías en las
inserciones, actualizaciones y borrados.

Bibliografía:

https://programas.cuaed.unam.mx/repositorio/moodle/pluginfile.php/872/mod_reso
urce/content/1/contenido/index.html

https://virtual.itca.edu.sv/Mediadores/dbd/u1/22_normalizacin.html

https://slideplayer.es/slide/5450405/